Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday, May 29, 2012 21:37:42 Mark wrote: Seriously, thank you for the information. That little piece of vital information was missing on the wiki. I added it: http://techbase.kde.org/Development/Tutorials/Plasma/QML/API#Dialog though you probably want to make it more acurate. Stating the obvious ... it's a wiki for a reason... :-) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tue, Jun 5, 2012 at 1:28 PM, Sebastian Kügler se...@kde.org wrote: On Tuesday, May 29, 2012 21:37:42 Mark wrote: Seriously, thank you for the information. That little piece of vital information was missing on the wiki. I added it: http://techbase.kde.org/Development/Tutorials/Plasma/QML/API#Dialogthough you probably want to make it more acurate. Stating the obvious ... it's a wiki for a reason... :-) Sure, nice comment... I am editing the wiki if i have something to add! I'm not a wiki pro nor do i have all the knowledge in those components. In fact, you, marco and aaron are probably _the_ ones that know nearly everything of those components so why don't you make my testing easier and share some of your knowledge in the wiki? I for one am actually looking in there to find information! I can't add what i don't know.. So please, add more information to the wiki since right now there is a lot of stuff missing hence my questions in this list about those components. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday, June 05, 2012 14:57:42 Mark wrote: On Tue, Jun 5, 2012 at 1:28 PM, Sebastian Kügler se...@kde.org wrote: On Tuesday, May 29, 2012 21:37:42 Mark wrote: Seriously, thank you for the information. That little piece of vital information was missing on the wiki. I added it: http://techbase.kde.org/Development/Tutorials/Plasma/QML/API#Dialogthoug h you probably want to make it more acurate. Stating the obvious ... it's a wiki for a reason... Sure, nice comment... I am editing the wiki if i have something to add! I'm not a wiki pro nor do i have all the knowledge in those components. In fact, you, marco and aaron are probably the ones that know nearly everything of those components so why don't you make my testing easier and share some of your knowledge in the wiki? I for one am actually looking in there to find information! I can't add what i don't know.. So please, add more information to the wiki since right now there is a lot of stuff missing hence my questions in this list about those components. I just re-read and saw that you already added it, so please nevermind. (It's the exact thing I meant, if it's just a little bit of information you want added which you just gathered, just add it -- which you did. Sorry for the misunderstanding. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Mon, May 28, 2012 at 12:34 AM, Aaron J. Seigo ase...@kde.org wrote: On Sunday, May 27, 2012 21:15:30 Mark wrote: You perhaps made the mental leap, for met it's still KDE without the SC. It's just the way people call KDE and that sticks. the SC seems like some expra part that people don't seem to remember. SC is part of the engineering jargon we use: it's the combined release of lots of separate modules. we don't use that term in public communication (marketing, etc) and there's a reason for that. regardless, what i said had nothing at all to do with the SC, but rather about the technical design of the code base and where the lines of separation exist. for those of us working on the technology, it's really important to understand the separation between the libraries, workspaces and applications because that affects the technical decisons we allow ourselves to make. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel This tooltip stuff just got a whole lot more complicated. I asked Martin (added to cc) for information about the window previews in QML. The reply i got was very surprising! -- Hi Mark, window previews can only be done in KWin and not in Plasma. IMHO the complete tooltip functionality has to be moved to KWin for exactly that reason. In fact I want to do more about it, like rendering unscaled window decorations around the preview which have a working close button. These are things only possible from inside KWin. Cheers -- Yeah, he wants to move tooltips to KWin! That certainly is interesting to say the least and that is kinda blocking what i'm doing right now with the tooltips. So how is this going to work if it's in KWin? How will this be put in a library if the tooltips depend on KWin.. Surely it's not the intention to let Dolphin depend on KWin for the tooltips? I would like to continue this tooltip effort and finish it, but i do need to know where this is going to. Are the window previews somehow going to be posible in QML outside of KWin so that everything stays the same as it is tight now only with QML? Or is everything going to move to KWin? In the latte one i really need help getting it there. KWin is complex! Feedback - lots of it - is certainly helpful now since i just don't know where tooltips are supposed to be ending up. :) And getting everyone informed so that we all know who is doing what seems to be helpful in this situation as well ^_- Cheers, Mark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday, May 29, 2012 10:28:20 Mark wrote: On Mon, May 28, 2012 at 12:34 AM, Aaron J. Seigo ase...@kde.org wrote: On Sunday, May 27, 2012 21:15:30 Mark wrote: You perhaps made the mental leap, for met it's still KDE without the SC. It's just the way people call KDE and that sticks. the SC seems like some expra part that people don't seem to remember. SC is part of the engineering jargon we use: it's the combined release of lots of separate modules. we don't use that term in public communication (marketing, etc) and there's a reason for that. regardless, what i said had nothing at all to do with the SC, but rather about the technical design of the code base and where the lines of separation exist. for those of us working on the technology, it's really important to understand the separation between the libraries, workspaces and applications because that affects the technical decisons we allow ourselves to make. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel This tooltip stuff just got a whole lot more complicated. I asked Martin (added to cc) for information about the window previews in QML. The reply i this is why we do things on public mailing lists instead of N different private threads. it makes it much more difficult to work together on things. Yeah, he wants to move tooltips to KWin! yes, this is Martin's current set of ideas: move everything to the window manager. i disagree and think it is a horrible idea for reasons i've explained elsewhere. So how is this going to work if it's in KWin? How will this be put in a library if the tooltips depend on KWin.. Surely it's not the intention to let Dolphin depend on KWin for the tooltips? well, yes, this is one reason what Martin suggested makes no sense. it's also completely irrelevant to the current task of separating out tooltips, so i don't think you need to worry about it. we have a working system right now for window previews. and yes, it relies on a compositer running, but that is a rutnime dependency .. for the task of creating a set of sharable tooltip classes, don't worry about reinventing the window preview code. there will be C++ involved, and that C++ can import an object into the QML that gives access to requesting window previews at a certain place in the tooltip (e.g. a new QML Item called WindowPreview that is actually a C++ class which handles all the previewing goodies; the QML would just create one or more of these WindowPreview objects and ensure they are placed correctly). from there, we'll see how nicely the current system works for this (we know from Plasma Active where we will run into challenges) and then we can start working on a reasonable solution for them if we need to (the current system may turn out to be good enough for now for plasma desktop). and please, keep discussion on the mailing list. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tue, May 29, 2012 at 1:16 PM, Aaron J. Seigo ase...@kde.org wrote: On Tuesday, May 29, 2012 10:28:20 Mark wrote: On Mon, May 28, 2012 at 12:34 AM, Aaron J. Seigo ase...@kde.org wrote: On Sunday, May 27, 2012 21:15:30 Mark wrote: You perhaps made the mental leap, for met it's still KDE without the SC. It's just the way people call KDE and that sticks. the SC seems like some expra part that people don't seem to remember. SC is part of the engineering jargon we use: it's the combined release of lots of separate modules. we don't use that term in public communication (marketing, etc) and there's a reason for that. regardless, what i said had nothing at all to do with the SC, but rather about the technical design of the code base and where the lines of separation exist. for those of us working on the technology, it's really important to understand the separation between the libraries, workspaces and applications because that affects the technical decisons we allow ourselves to make. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel This tooltip stuff just got a whole lot more complicated. I asked Martin (added to cc) for information about the window previews in QML. The reply i this is why we do things on public mailing lists instead of N different private threads. it makes it much more difficult to work together on things. Yeah, he wants to move tooltips to KWin! yes, this is Martin's current set of ideas: move everything to the window manager. i disagree and think it is a horrible idea for reasons i've explained elsewhere. That's going to be a nice battle between you two at Akademy ;-) So how is this going to work if it's in KWin? How will this be put in a library if the tooltips depend on KWin.. Surely it's not the intention to let Dolphin depend on KWin for the tooltips? well, yes, this is one reason what Martin suggested makes no sense. it's also completely irrelevant to the current task of separating out tooltips, so i don't think you need to worry about it. we have a working system right now for window previews. and yes, it relies on a compositer running, but that is a rutnime dependency .. for the task of creating a set of sharable tooltip classes, don't worry about reinventing the window preview code. there will be C++ involved, and that C++ can import an object into the QML that gives access to requesting window previews at a certain place in the tooltip (e.g. a new QML Item called WindowPreview that is actually a C++ class which handles all the previewing goodies; the QML would just create one or more of these WindowPreview objects and ensure they are placed correctly). Ahh oke, i get it. For the moment i can even try to use a QGraphicsProxyWidget and just send WindowPreview to QML. It actually seems fairly easy to do as described here: http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets-cpp.html or if it doesn't work i can always put a big red squared stub in it as placeholder ^_- from there, we'll see how nicely the current system works for this (we know from Plasma Active where we will run into challenges) and then we can start working on a reasonable solution for them if we need to (the current system may turn out to be good enough for now for plasma desktop). and please, keep discussion on the mailing list. It does seem like this will be useful anyway and just one small part that is problematic (window previews) so I'll continue with it and get it working. Thank you for the clarification -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday 29 May 2012, Mark wrote: can import an object into the QML that gives access to requesting window previews at a certain place in the tooltip (e.g. a new QML Item called WindowPreview that is actually a C++ class which handles all the previewing goodies; the QML would just create one or more of these WindowPreview objects and ensure they are placed correctly). Ahh oke, i get it. For the moment i can even try to use a QGraphicsProxyWidget and just send WindowPreview to QML. It actually seems fairly easy to do as described here: http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidget s-cpp.html or if it doesn't work i can always put a big red squared stub in it as placeholder ^_- probably doesn't work since when windowpreview is a proxywidget doesn't have a read window id anymore: the window preview mechanism works by setting an Atom on the actual X11 window that asks for a preview of a particular window to be drawn at cerain coordinates by the compositor. the nearest thing to what you need is the old windowstrip plasmoid that lives in plasma-mobile repository -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tue, May 29, 2012 at 1:59 PM, Marco Martin notm...@gmail.com wrote: On Tuesday 29 May 2012, Mark wrote: can import an object into the QML that gives access to requesting window previews at a certain place in the tooltip (e.g. a new QML Item called WindowPreview that is actually a C++ class which handles all the previewing goodies; the QML would just create one or more of these WindowPreview objects and ensure they are placed correctly). Ahh oke, i get it. For the moment i can even try to use a QGraphicsProxyWidget and just send WindowPreview to QML. It actually seems fairly easy to do as described here: http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidget s-cpp.html or if it doesn't work i can always put a big red squared stub in it as placeholder ^_- probably doesn't work since when windowpreview is a proxywidget doesn't have a read window id anymore: the window preview mechanism works by setting an Atom on the actual X11 window that asks for a preview of a particular window to be drawn at cerain coordinates by the compositor. Then we follow the approach from this http://get.qt.nokia.com/training/QtQuickforCppDevelopers/slides/qml-cpp-integration.pdf. Custom painting on top of a QML item. That should certainly be possible since you just make the WindowPreview in C++ and let it paint on a QML item. Perhaps nasty but that probably works. I could be a bit naive, but i don't really see an issue on getting the preview to QML. Perhaps i still need to hit a big giant wall that stops me. ^_- the nearest thing to what you need is the old windowstrip plasmoid that lives in plasma-mobile repository Will take a look at that one. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday 29 May 2012, Mark wrote: Then we follow the approach from this http://get.qt.nokia.com/training/QtQuickforCppDevelopers/slides/qml-cpp-int egration.pdf. Custom painting on top of a QML item. That should certainly be possible since you just make the WindowPreview in C++ and let it paint on a QML item. Perhaps nasty but that probably works. - the difference here is that who is painting is not the c++ side of that application... is another process entirely: kwin :p as is said, the windowstrip applet does everything you need -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday, May 29, 2012 13:53:47 Mark wrote: Ahh oke, i get it. For the moment i can even try to use a QGraphicsProxyWidget and just send WindowPreview to QML. It actually seems fairly easy to do as described here: http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets -cpp.html or if it doesn't work i can always put a big red squared stub in it as placeholder ^_- heh.. yes.. for getting devel going, a placeholder is fine. as marco noted, a proxy widget isn't going to be much help. what is needed is a QML element that knows of the top level window so it can set xatoms as needed (and later whatever we do for wayland, etc). so to me it makes sense to have this particular QML item be a C++ subclass of QDeclarativeItem that is tightly coupled to the window implementation and has a property for the window id to show. one question would be whether to support showing multiple windows in one of these items, or one window per item. i lean towards one window per item for ease of implementation and flexibility of use inside the QML. (and yes, with the xatom approach we'll run into repaint latency issues if these are highly animated ... but let's start with this and then start experimenting from there.) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tue, May 29, 2012 at 2:24 PM, Aaron J. Seigo ase...@kde.org wrote:
On Tuesday, May 29, 2012 13:53:47 Mark wrote:
Ahh oke, i get it.
For the moment i can even try to use a QGraphicsProxyWidget and just send
WindowPreview to QML. It actually seems fairly easy to do as described
here:
http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets
-cpp.html or
if it doesn't work i can always put a big red squared stub in it as
placeholder ^_-
heh.. yes.. for getting devel going, a placeholder is fine.
as marco noted, a proxy widget isn't going to be much help. what is needed
is
a QML element that knows of the top level window so it can set xatoms as
needed (and later whatever we do for wayland, etc).
so to me it makes sense to have this particular QML item be a C++ subclass
of
QDeclarativeItem that is tightly coupled to the window implementation and
has
a property for the window id to show.
one question would be whether to support showing multiple windows in one of
these items, or one window per item. i lean towards one window per item for
ease of implementation and flexibility of use inside the QML.
Certainly 1! then a list of those elements when there are multiple.
Showing it would probably be with either a Row {} or Column {} depending on
the orientation.
(and yes, with the xatom approach we'll run into repaint latency issues if
these are highly animated ... but let's start with this and then start
experimenting from there.)
--
Aaron J. Seigo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tue, May 29, 2012 at 2:29 PM, Mark mark...@gmail.com wrote:
On Tue, May 29, 2012 at 2:24 PM, Aaron J. Seigo ase...@kde.org wrote:
On Tuesday, May 29, 2012 13:53:47 Mark wrote:
Ahh oke, i get it.
For the moment i can even try to use a QGraphicsProxyWidget and just
send
WindowPreview to QML. It actually seems fairly easy to do as described
here:
http://qt-project.org/doc/qt-4.8/declarative-cppextensions-qwidgets-qwidgets
-cpp.html or
if it doesn't work i can always put a big red squared stub in it as
placeholder ^_-
heh.. yes.. for getting devel going, a placeholder is fine.
as marco noted, a proxy widget isn't going to be much help. what is
needed is
a QML element that knows of the top level window so it can set xatoms as
needed (and later whatever we do for wayland, etc).
so to me it makes sense to have this particular QML item be a C++
subclass of
QDeclarativeItem that is tightly coupled to the window implementation and
has
a property for the window id to show.
one question would be whether to support showing multiple windows in one
of
these items, or one window per item. i lean towards one window per item
for
ease of implementation and flexibility of use inside the QML.
Certainly 1! then a list of those elements when there are multiple.
Showing it would probably be with either a Row {} or Column {} depending
on the orientation.
(and yes, with the xatom approach we'll run into repaint latency issues if
these are highly animated ... but let's start with this and then start
experimenting from there.)
--
Aaron J. Seigo
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
http://techbase.kde.org/Development/Tutorials/Plasma/QML/API#Dialog now i
remember one of the issues i had with a Dialog. What's the recommended way
of changing it's width and/or height?
width and height are read only ...
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday, May 29, 2012 19:42:53 Mark wrote: remember one of the issues i had with a Dialog. What's the recommended way of changing it's width and/or height? it should, hopefully, resize to accomodate the size of the content. Marco: is there a way to signal to the dialog what the good size for the content is? -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tuesday 29 May 2012, Aaron J. Seigo wrote: On Tuesday, May 29, 2012 19:42:53 Mark wrote: remember one of the issues i had with a Dialog. What's the recommended way of changing it's width and/or height? it should, hopefully, resize to accomodate the size of the content. Marco: is there a way to signal to the dialog what the good size for the content is? the dialog should always follow its main item geometry, resize the contents and the dialog will sync -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Tue, May 29, 2012 at 8:55 PM, Marco Martin notm...@gmail.com wrote:
On Tuesday 29 May 2012, Aaron J. Seigo wrote:
On Tuesday, May 29, 2012 19:42:53 Mark wrote:
remember one of the issues i had with a Dialog. What's the recommended
way of changing it's width and/or height?
it should, hopefully, resize to accomodate the size of the content.
Marco:
is there a way to signal to the dialog what the good size for the
content is?
the dialog should always follow its main item geometry, resize the contents
and the dialog will sync
Interesting, so i can make the main item in fullscreen and still have a
fullscreen component. Nenermind my ApplicationWindow proposal, this is a
lot more fun to tease our beloved users ;-)
Anyone up for a user test of:
PlasmaCore.Dialog
{
Rectangle
{
width: Math.random() * 1680
height: Math.random() * 1050
}
}
(now i probably wrote that wrong but you get the idea)
I hope you do smile the sarcasm ^_-
Seriously, thank you for the information. That little piece of vital
information was missing on the wiki. I added it:
http://techbase.kde.org/Development/Tutorials/Plasma/QML/API#Dialog though
you probably want to make it more acurate.
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Saturday, May 26, 2012 03:08:41 Mark wrote: For dolphin i can understand the reason to have it's own tooltip class because it wants to fetch the tooltip data in a separate process in order to prevent a crash in the tooltip from crashing dolphin. there is no reason this could not be accomodated in the Plasma tooltips. the file icon would specify that it has a tooltip, when shown the manager sends it the about to show signal, it starts the process of fetching data, when that arrives it actually populates the tooltip content. To get this in a workable situation where anyone can use the tooltips as they seem right we probably have to make a new ToolTipManager altogether. there are 3 classes in Plasma's tooltip system: ToolTipManager - this one keeps track of which items have tooltips, owns the tooltip UI, shows/hides the actual tooltip and tells widgets when they should be updating their content because the tooltip will be shown (and again when to stop because it will be hidden) ToolTipContent - this one stores what is in the tooltip itself and is used by the widget to tell the manager what should be shown ToolTip - this is a private class, and handles the UI display styling belongs to ToolTip. definition belongs to ToolTipContent. management to ToolTipManager. so if it is an issue of styling and controlling that style, then ToolTip would need adjustment and perhaps ToolTipContent to direct which style to use. ToolTipManager probably wouldn't get touched. however, do we really need radically different visual styles? all three application have a pixmap on the left and text on the right. the text on the right changes a fair amount from app to app, though: in systemsettings it is a category, a separator and a listing; in dolpin, it's a title, a separator, and a nicely aligned table of metadata. in Plasma we see very similar arrangements in the clock with multiple timezones and in the pager displaying multiple windows. so i'm not sure it's a styling issue at all, and would in fact suggest that having a consistent presentation would be an improvement over the current situation. there are things that could use some improving, however: * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it usable with QWidgets and ready for QML2 is probably important. * it assumes one tooltip per widget; this was an issue for folderview, which it worked around by putting an invisible item over the item the mouse was over. perhaps this could have been different in folderview, however, and isn't a real problem in practice. * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and toolTipAboutToHide in items that have tooltips. it would be nice to have a more elegant way to do this, in particular a mechanism that would work nicely with QML2 and which allows the widget with the tooltip to define the connection. so there are certainly some design issues to be addressed. as for content, it would be interesting to see if ToolTipContent could be extended in some way to more easily accomodate the needs of things like showing a table of data (perhaps a QHashQString, QString .. what does dolphin use for this datastructure?) The current one is _way_ to much tailored at tooltips for the tasks plasmoid and doesn't leave much room for customization (correct me if i'm wrong). the tooltips in Plasma are used by pretty much everything in Plasma. the only thing specific to the tasks plasmoid in them is the ability to view previews of windows. most things that use the tooltips ignore this feature cmpletely as it is not relevant to them. it is a requirement of some uses, such as in the tasks widget. so i wouldn't say that the current tooltips are too tailored to the tasks widget as they are used, well, everywhere. I would like to suggest a ToolTipManager with styles! Not themes! I perhaps this can be determined by the content rather than by explicitly setting the style in the application, which is probably just asking for inconsistencies. i also don't like the idea of having to subclass things just to get a nice tooltip in an application. it's both too much effort and too much of an invitation for inconsistency. i realy wonder if the existing Plasma::ToolTipManager could not just be used in system settings already? if it is because it is too QGraphicsView centric, let's fix that first ... i do think this is a good project that can bring a very nice improvement in looks and consistency... thanks for taking it on! :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Sun, May 27, 2012 at 7:43 PM, Aaron J. Seigo ase...@kde.org wrote: On Saturday, May 26, 2012 03:08:41 Mark wrote: For dolphin i can understand the reason to have it's own tooltip class because it wants to fetch the tooltip data in a separate process in order to prevent a crash in the tooltip from crashing dolphin. there is no reason this could not be accomodated in the Plasma tooltips. the file icon would specify that it has a tooltip, when shown the manager sends it the about to show signal, it starts the process of fetching data, when that arrives it actually populates the tooltip content. To get this in a workable situation where anyone can use the tooltips as they seem right we probably have to make a new ToolTipManager altogether. there are 3 classes in Plasma's tooltip system: ToolTipManager - this one keeps track of which items have tooltips, owns the tooltip UI, shows/hides the actual tooltip and tells widgets when they should be updating their content because the tooltip will be shown (and again when to stop because it will be hidden) ToolTipContent - this one stores what is in the tooltip itself and is used by the widget to tell the manager what should be shown ToolTip - this is a private class, and handles the UI display styling belongs to ToolTip. definition belongs to ToolTipContent. management to ToolTipManager. so if it is an issue of styling and controlling that style, then ToolTip would need adjustment and perhaps ToolTipContent to direct which style to use. ToolTipManager probably wouldn't get touched. however, do we really need radically different visual styles? all three application have a pixmap on the left and text on the right. the text on the right changes a fair amount from app to app, though: in systemsettings it is a category, a separator and a listing; in dolpin, it's a title, a separator, and a nicely aligned table of metadata. in Plasma we see very similar arrangements in the clock with multiple timezones and in the pager displaying multiple windows. For System Settings, the listing has icons as well. Is this possible with Plasma's tooltip classes? At the moment, it uses QWidgets (QIcon and QLabel to be precise) with layouts, as the previous QPainter based code did not handle RTL layouting properly, and quite often had rendering errors (text running outside the painted background, etc) so i'm not sure it's a styling issue at all, and would in fact suggest that having a consistent presentation would be an improvement over the current situation. Agreed, plus it would reduce the amount of code used :) there are things that could use some improving, however: * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it usable with QWidgets and ready for QML2 is probably important. * it assumes one tooltip per widget; this was an issue for folderview, which it worked around by putting an invisible item over the item the mouse was over. perhaps this could have been different in folderview, however, and isn't a real problem in practice. * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and toolTipAboutToHide in items that have tooltips. it would be nice to have a more elegant way to do this, in particular a mechanism that would work nicely with QML2 and which allows the widget with the tooltip to define the connection. For System Settings, the items are in a QGridView, so not sure where the toolTipAboutToShow, etc methods would go here (on the items themselves, or the view?) so there are certainly some design issues to be addressed. as for content, it would be interesting to see if ToolTipContent could be extended in some way to more easily accomodate the needs of things like showing a table of data (perhaps a QHashQString, QString .. what does dolphin use for this datastructure?) The current one is _way_ to much tailored at tooltips for the tasks plasmoid and doesn't leave much room for customization (correct me if i'm wrong). the tooltips in Plasma are used by pretty much everything in Plasma. the only thing specific to the tasks plasmoid in them is the ability to view previews of windows. most things that use the tooltips ignore this feature cmpletely as it is not relevant to them. it is a requirement of some uses, such as in the tasks widget. so i wouldn't say that the current tooltips are too tailored to the tasks widget as they are used, well, everywhere. I would like to suggest a ToolTipManager with styles! Not themes! I perhaps this can be determined by the content rather than by explicitly setting the style in the application, which is probably just asking for inconsistencies. i also don't like the idea of having to subclass things just to get a nice tooltip in an application. it's both too much effort and too much of an invitation for inconsistency. i realy wonder if the existing Plasma::ToolTipManager could not just be used in
Re: The tooltip state. Not that good. Proposal for improvement.
On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo ase...@kde.org wrote: On Saturday, May 26, 2012 03:08:41 Mark wrote: For dolphin i can understand the reason to have it's own tooltip class because it wants to fetch the tooltip data in a separate process in order to prevent a crash in the tooltip from crashing dolphin. there is no reason this could not be accomodated in the Plasma tooltips. the file icon would specify that it has a tooltip, when shown the manager sends it the about to show signal, it starts the process of fetching data, when that arrives it actually populates the tooltip content. That could be some valuable info for Peter (Dolphin). Adding him in the cc just in case. To get this in a workable situation where anyone can use the tooltips as they seem right we probably have to make a new ToolTipManager altogether. there are 3 classes in Plasma's tooltip system: ToolTipManager - this one keeps track of which items have tooltips, owns the tooltip UI, shows/hides the actual tooltip and tells widgets when they should be updating their content because the tooltip will be shown (and again when to stop because it will be hidden) ToolTipContent - this one stores what is in the tooltip itself and is used by the widget to tell the manager what should be shown ToolTip - this is a private class, and handles the UI display styling belongs to ToolTip. definition belongs to ToolTipContent. management to ToolTipManager. so if it is an issue of styling and controlling that style, then ToolTip would need adjustment and perhaps ToolTipContent to direct which style to use. ToolTipManager probably wouldn't get touched. however, do we really need radically different visual styles? Well, i guess we need.. Just the tasks plasmoid has 2 different tooltip styles. One for the app launcher icon and one for the launched apps with a preview. System settings needs another different style and dolphin needs yet another different style. all three application have a pixmap on the left and text on the right. the text on the right changes a fair amount from app to app, though: in systemsettings it is a category, a separator and a listing; in dolpin, it's a title, a separator, and a nicely aligned table of metadata. in Plasma we see very similar arrangements in the clock with multiple timezones and in the pager displaying multiple windows. so i'm not sure it's a styling issue at all, and would in fact suggest that having a consistent presentation would be an improvement over the current situation. there are things that could use some improving, however: * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it usable with QWidgets and ready for QML2 is probably important. * it assumes one tooltip per widget; this was an issue for folderview, which it worked around by putting an invisible item over the item the mouse was over. perhaps this could have been different in folderview, however, and isn't a real problem in practice. * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and toolTipAboutToHide in items that have tooltips. it would be nice to have a more elegant way to do this, in particular a mechanism that would work nicely with QML2 and which allows the widget with the tooltip to define the connection. so there are certainly some design issues to be addressed. as for content, it would be interesting to see if ToolTipContent could be extended in some way to more easily accomodate the needs of things like showing a table of data (perhaps a QHashQString, QString .. what does dolphin use for this datastructure?) Dolphin created tooltips based on KFileItem. They then get send to dolphin's internal FileMetaDataToolTip class that makes puts it all together on top of a QWidget. The current one is _way_ to much tailored at tooltips for the tasks plasmoid and doesn't leave much room for customization (correct me if i'm wrong). the tooltips in Plasma are used by pretty much everything in Plasma. the only thing specific to the tasks plasmoid in them is the ability to view previews of windows. most things that use the tooltips ignore this feature cmpletely as it is not relevant to them. it is a requirement of some uses, such as in the tasks widget. so i wouldn't say that the current tooltips are too tailored to the tasks widget as they are used, well, everywhere. I would like to suggest a ToolTipManager with styles! Not themes! I perhaps this can be determined by the content rather than by explicitly setting the style in the application, which is probably just asking for inconsistencies. i also don't like the idea of having to subclass things just to get a nice tooltip in an application. it's both too much effort and too much of an invitation for inconsistency. Subclassing did seem like a nice but a little to complex for what it actually needs to do. So, no subclassing
Re: The tooltip state. Not that good. Proposal for improvement.
On Sun, May 27, 2012 at 2:44 PM, Mark mark...@gmail.com wrote: On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo ase...@kde.org wrote: On Saturday, May 26, 2012 03:08:41 Mark wrote: For dolphin i can understand the reason to have it's own tooltip class because it wants to fetch the tooltip data in a separate process in order to prevent a crash in the tooltip from crashing dolphin. there is no reason this could not be accomodated in the Plasma tooltips. the file icon would specify that it has a tooltip, when shown the manager sends it the about to show signal, it starts the process of fetching data, when that arrives it actually populates the tooltip content. That could be some valuable info for Peter (Dolphin). Adding him in the cc just in case. To get this in a workable situation where anyone can use the tooltips as they seem right we probably have to make a new ToolTipManager altogether. there are 3 classes in Plasma's tooltip system: ToolTipManager - this one keeps track of which items have tooltips, owns the tooltip UI, shows/hides the actual tooltip and tells widgets when they should be updating their content because the tooltip will be shown (and again when to stop because it will be hidden) ToolTipContent - this one stores what is in the tooltip itself and is used by the widget to tell the manager what should be shown ToolTip - this is a private class, and handles the UI display styling belongs to ToolTip. definition belongs to ToolTipContent. management to ToolTipManager. so if it is an issue of styling and controlling that style, then ToolTip would need adjustment and perhaps ToolTipContent to direct which style to use. ToolTipManager probably wouldn't get touched. however, do we really need radically different visual styles? Well, i guess we need.. Just the tasks plasmoid has 2 different tooltip styles. One for the app launcher icon and one for the launched apps with a preview. System settings needs another different style and dolphin needs yet another different style. all three application have a pixmap on the left and text on the right. the text on the right changes a fair amount from app to app, though: in systemsettings it is a category, a separator and a listing; in dolpin, it's a title, a separator, and a nicely aligned table of metadata. in Plasma we see very similar arrangements in the clock with multiple timezones and in the pager displaying multiple windows. so i'm not sure it's a styling issue at all, and would in fact suggest that having a consistent presentation would be an improvement over the current situation. there are things that could use some improving, however: * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it usable with QWidgets and ready for QML2 is probably important. * it assumes one tooltip per widget; this was an issue for folderview, which it worked around by putting an invisible item over the item the mouse was over. perhaps this could have been different in folderview, however, and isn't a real problem in practice. * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and toolTipAboutToHide in items that have tooltips. it would be nice to have a more elegant way to do this, in particular a mechanism that would work nicely with QML2 and which allows the widget with the tooltip to define the connection. so there are certainly some design issues to be addressed. as for content, it would be interesting to see if ToolTipContent could be extended in some way to more easily accomodate the needs of things like showing a table of data (perhaps a QHashQString, QString .. what does dolphin use for this datastructure?) Dolphin created tooltips based on KFileItem. They then get send to dolphin's internal FileMetaDataToolTip class that makes puts it all together on top of a QWidget. The current one is _way_ to much tailored at tooltips for the tasks plasmoid and doesn't leave much room for customization (correct me if i'm wrong). the tooltips in Plasma are used by pretty much everything in Plasma. the only thing specific to the tasks plasmoid in them is the ability to view previews of windows. most things that use the tooltips ignore this feature cmpletely as it is not relevant to them. it is a requirement of some uses, such as in the tasks widget. so i wouldn't say that the current tooltips are too tailored to the tasks widget as they are used, well, everywhere. I would like to suggest a ToolTipManager with styles! Not themes! I perhaps this can be determined by the content rather than by explicitly setting the style in the application, which is probably just asking for inconsistencies. i also don't like the idea of having to subclass things just to get a nice tooltip in an application. it's both too much effort and too much of an invitation for inconsistency. Subclassing did seem like a
Re: The tooltip state. Not that good. Proposal for improvement.
On Sunday, May 27, 2012 14:44:50 Mark wrote: On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo ase...@kde.org wrote: On Saturday, May 26, 2012 03:08:41 Mark wrote: For dolphin i can understand the reason to have it's own tooltip class because it wants to fetch the tooltip data in a separate process in order to prevent a crash in the tooltip from crashing dolphin. there is no reason this could not be accomodated in the Plasma tooltips. the file icon would specify that it has a tooltip, when shown the manager sends it the about to show signal, it starts the process of fetching data, when that arrives it actually populates the tooltip content. That could be some valuable info for Peter (Dolphin). Adding him in the cc just in case. To get this in a workable situation where anyone can use the tooltips as they seem right we probably have to make a new ToolTipManager altogether. there are 3 classes in Plasma's tooltip system: ToolTipManager - this one keeps track of which items have tooltips, owns the tooltip UI, shows/hides the actual tooltip and tells widgets when they should be updating their content because the tooltip will be shown (and again when to stop because it will be hidden) ToolTipContent - this one stores what is in the tooltip itself and is used by the widget to tell the manager what should be shown ToolTip - this is a private class, and handles the UI display styling belongs to ToolTip. definition belongs to ToolTipContent. management to ToolTipManager. so if it is an issue of styling and controlling that style, then ToolTip would need adjustment and perhaps ToolTipContent to direct which style to use. ToolTipManager probably wouldn't get touched. however, do we really need radically different visual styles? Well, i guess we need.. Just the tasks plasmoid has 2 different tooltip styles. One for the app launcher icon and one for the launched apps with a preview. System settings needs another different style and dolphin needs yet another different style. all three application have a pixmap on the left and text on the right. the text on the right changes a fair amount from app to app, though: in systemsettings it is a category, a separator and a listing; in dolpin, it's a title, a separator, and a nicely aligned table of metadata. in Plasma we see very similar arrangements in the clock with multiple timezones and in the pager displaying multiple windows. so i'm not sure it's a styling issue at all, and would in fact suggest that having a consistent presentation would be an improvement over the current situation. there are things that could use some improving, however: * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it usable with QWidgets and ready for QML2 is probably important. * it assumes one tooltip per widget; this was an issue for folderview, which it worked around by putting an invisible item over the item the mouse was over. perhaps this could have been different in folderview, however, and isn't a real problem in practice. * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and toolTipAboutToHide in items that have tooltips. it would be nice to have a more elegant way to do this, in particular a mechanism that would work nicely with QML2 and which allows the widget with the tooltip to define the connection. so there are certainly some design issues to be addressed. as for content, it would be interesting to see if ToolTipContent could be extended in some way to more easily accomodate the needs of things like showing a table of data (perhaps a QHashQString, QString .. what does dolphin use for this datastructure?) Dolphin created tooltips based on KFileItem. They then get send to dolphin's internal FileMetaDataToolTip class that makes puts it all together on top of a QWidget. right; so for Dolphin, either subclassing ToolTipContent or making a factory method to turn a KFileItem into a ToolTipContent might be best. and then ToolTipManager can handle the rest from there. OR ... ToolTipContent to have a constructor that takes a KFileItem and which does the translation internally. this would only make sense if there is more than one application in which a tooltip on a file would be useful. my guess is yes, but that's just a guess. looking for these apps would be a good idea first. what could be done is an iterative approach: * make a subclass of ToolTipContent in libkonq that has this KFileItem mutator ability * if there is use for it outside of kde-baseapps, at that point merge that code with ToolTipContent Step 1: How about i refactor the private ToolTip class to inherit from QDeclarativeView. +1 Step 2: Rewrite the current drawing logic for ToolTip in a QML file (TOOLTIP_STYLE_DEFAULT.qml). +1 Step 3: Introduce and enum:
Re: The tooltip state. Not that good. Proposal for improvement.
On Sunday, May 27, 2012 19:55:58 Ben Cooksley wrote: For System Settings, the listing has icons as well. Is this possible with Plasma's tooltip classes? yes, as Marco pointed out. but since we're looking at some re-work of the implementation anyways, it might make sense to give ToolTipContent the ability to have a set of items. i see that System Settings is using a QAbstractItemModel here (or a subclass of that, didn't look further :) and passing in a QModelIndex. so perhaps ToolTipContent gets the ability to have such an index (perhaps a persistent index?) and that is then very easily used from QML. this would allow us to do much prettier arrangements, including in places like the pager and clocks. At the moment, it uses QWidgets (QIcon and QLabel to be precise) with layouts, as the previous QPainter based code did not handle RTL layouting properly, and quite often had rendering errors (text running outside the painted background, etc) yes, we'll move to QML for all this. For System Settings, the items are in a QGridView, so not sure where the toolTipAboutToShow, etc methods would go here (on the items themselves, or the view?) i agree wit Marco's suggestion.. we'll need different mechanisms for different kinds of targets. and one would be written for QItemView that starts watching mouse events on the view when the view is hovered (and stops when it is unhovered) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Sun, May 27, 2012 at 5:48 PM, Aaron J. Seigo ase...@kde.org wrote: On Sunday, May 27, 2012 14:44:50 Mark wrote: On Sun, May 27, 2012 at 9:43 AM, Aaron J. Seigo ase...@kde.org wrote: On Saturday, May 26, 2012 03:08:41 Mark wrote: For dolphin i can understand the reason to have it's own tooltip class because it wants to fetch the tooltip data in a separate process in order to prevent a crash in the tooltip from crashing dolphin. there is no reason this could not be accomodated in the Plasma tooltips. the file icon would specify that it has a tooltip, when shown the manager sends it the about to show signal, it starts the process of fetching data, when that arrives it actually populates the tooltip content. That could be some valuable info for Peter (Dolphin). Adding him in the cc just in case. To get this in a workable situation where anyone can use the tooltips as they seem right we probably have to make a new ToolTipManager altogether. there are 3 classes in Plasma's tooltip system: ToolTipManager - this one keeps track of which items have tooltips, owns the tooltip UI, shows/hides the actual tooltip and tells widgets when they should be updating their content because the tooltip will be shown (and again when to stop because it will be hidden) ToolTipContent - this one stores what is in the tooltip itself and is used by the widget to tell the manager what should be shown ToolTip - this is a private class, and handles the UI display styling belongs to ToolTip. definition belongs to ToolTipContent. management to ToolTipManager. so if it is an issue of styling and controlling that style, then ToolTip would need adjustment and perhaps ToolTipContent to direct which style to use. ToolTipManager probably wouldn't get touched. however, do we really need radically different visual styles? Well, i guess we need.. Just the tasks plasmoid has 2 different tooltip styles. One for the app launcher icon and one for the launched apps with a preview. System settings needs another different style and dolphin needs yet another different style. all three application have a pixmap on the left and text on the right. the text on the right changes a fair amount from app to app, though: in systemsettings it is a category, a separator and a listing; in dolpin, it's a title, a separator, and a nicely aligned table of metadata. in Plasma we see very similar arrangements in the clock with multiple timezones and in the pager displaying multiple windows. so i'm not sure it's a styling issue at all, and would in fact suggest that having a consistent presentation would be an improvement over the current situation. there are things that could use some improving, however: * Plasma::ToolTipManager is fairly focused on QGraphicsWidget. making it usable with QWidgets and ready for QML2 is probably important. * it assumes one tooltip per widget; this was an issue for folderview, which it worked around by putting an invisible item over the item the mouse was over. perhaps this could have been different in folderview, however, and isn't a real problem in practice. * ToolTipManager uses QMetaObject::invokeMethod to call toolTipAboutToShow and toolTipAboutToHide in items that have tooltips. it would be nice to have a more elegant way to do this, in particular a mechanism that would work nicely with QML2 and which allows the widget with the tooltip to define the connection. so there are certainly some design issues to be addressed. as for content, it would be interesting to see if ToolTipContent could be extended in some way to more easily accomodate the needs of things like showing a table of data (perhaps a QHashQString, QString .. what does dolphin use for this datastructure?) Dolphin created tooltips based on KFileItem. They then get send to dolphin's internal FileMetaDataToolTip class that makes puts it all together on top of a QWidget. right; so for Dolphin, either subclassing ToolTipContent or making a factory method to turn a KFileItem into a ToolTipContent might be best. and then ToolTipManager can handle the rest from there. OR ... ToolTipContent to have a constructor that takes a KFileItem and which does the translation internally. this would only make sense if there is more than one application in which a tooltip on a file would be useful. my guess is yes, but that's just a guess. looking for these apps would be a good idea first. what could be done is an iterative approach: * make a subclass of ToolTipContent in libkonq that has this KFileItem mutator ability * if there is use for it outside of kde-baseapps, at that point merge that code with ToolTipContent Step 1: How about i refactor the private ToolTip
Re: The tooltip state. Not that good. Proposal for improvement.
On Sunday, May 27, 2012 18:22:10 Mark wrote: Is this (tooltip refactoring) going to be for frameworks only or for KDE 4.10(?) as well? there's no reason we could not start using the new tooltips classes in 4.x code AND for the library to be part of Frameworks as well. there's a number of reasons we quite purposefully stopped calling everything KDE and in the process broke out the naming and even to some degree the marketing for the libraries (Platform 4.x, Frameworks 5.x), workspaces and applications. they are independent pieces. anytime we ask a question that implies the applications are welded to the workspaces / applications, or the applications to the workspaces, ... etc .. we're regressing. they are independent. there is no KDE 5. there never will be a KDE 5. there will be a KDE Frameworks 5. and workspaces? we'll decide as we go when and what to use where and how. it is amazingly freeing when you make that mental leap :) so go ahead. develop the classes with the goal of making it part of Frameworks. and we'll use it whenever we damn well feel like it. ;) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Sun, May 27, 2012 at 8:02 PM, Aaron J. Seigo ase...@kde.org wrote: On Sunday, May 27, 2012 18:22:10 Mark wrote: Is this (tooltip refactoring) going to be for frameworks only or for KDE 4.10(?) as well? there's no reason we could not start using the new tooltips classes in 4.x code AND for the library to be part of Frameworks as well. there's a number of reasons we quite purposefully stopped calling everything KDE and in the process broke out the naming and even to some degree the marketing for the libraries (Platform 4.x, Frameworks 5.x), workspaces and applications. they are independent pieces. anytime we ask a question that implies the applications are welded to the workspaces / applications, or the applications to the workspaces, ... etc .. we're regressing. they are independent. there is no KDE 5. there never will be a KDE 5. there will be a KDE Frameworks 5. and workspaces? we'll decide as we go when and what to use where and how. it is amazingly freeing when you make that mental leap :) so go ahead. develop the classes with the goal of making it part of Frameworks. and we'll use it whenever we damn well feel like it. ;) -- Aaron J. Seigo You perhaps made the mental leap, for met it's still KDE without the SC. It's just the way people call KDE and that sticks. the SC seems like some expra part that people don't seem to remember. Either way, first i'm going to start hacking on the internal tooltip class and without making it a library. We'il see from there :) One step at a time. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Sunday, May 27, 2012 21:15:30 Mark wrote: You perhaps made the mental leap, for met it's still KDE without the SC. It's just the way people call KDE and that sticks. the SC seems like some expra part that people don't seem to remember. SC is part of the engineering jargon we use: it's the combined release of lots of separate modules. we don't use that term in public communication (marketing, etc) and there's a reason for that. regardless, what i said had nothing at all to do with the SC, but rather about the technical design of the code base and where the lines of separation exist. for those of us working on the technology, it's really important to understand the separation between the libraries, workspaces and applications because that affects the technical decisons we allow ourselves to make. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
On Sat, May 26, 2012 at 4:09 AM, Mark mark...@gmail.com wrote:
Op 26 mei 2012 03:08 schreef Mark mark...@gmail.com het volgende:
Hi,
While trying to fix some blur issues on tooltips i found myself digging
deeper in ... other issues.
For starters, there is no tooltip consistency!
- Dolphin uses it's own tooltip classes.
- System Settings uses it's own tooltip classes.
- The plasma panels use the Plasma::ToolTipManager class - like it
should be!
That's only for the consistency using classes! The style also differs
and only the last one has blur behind it [1].
For dolphin i can understand the reason to have it's own tooltip class
because it wants to fetch the tooltip data in a separate process in order
to prevent a crash in the tooltip from crashing dolphin.
To get this in a workable situation where anyone can use the tooltips as
they seem right we probably have to make a new ToolTipManager altogether.
The current one is _way_ to much tailored at tooltips for the tasks
plasmoid and doesn't leave much room for customization (correct me if i'm
wrong). I would like to suggest a ToolTipManager with styles! Not themes! I
repeat, not themes! Just style as in which data is being displayed where.
The plasma theme is still the one to be for the theme so nothing changes
there. What i think that should be possible is defining a ToolTip Theme. Or
i actually think it's required if the plasma tooltip stuff is to be used in
places where the tooltip can look completely different (again, like
dolphin).
For example (in ascii art).
ToolTipTheme - Dolphin
|---| test...
|ICON|
|---| test...
text...
ToolTipTheme - TasksAppLauncher
|---| APP NAME
|ICON| APP DESCRIPTION
|---|
ToolTipTheme - TasksPopup
|--|
|--|
|--|
|--|
|--|
|--|
|---|
|ICON| APP DESCRIPTION
|---|
That should make the intention clear even though the ascii art sucks ;)
I would say that we need an abstract theme class:
class ToolTipThemeAbstract
{
virtual QGraphisWidget* getTheme() = 0;
}
and some classes that implement it:
class ToolTipThemeDolphin : public ToolTipThemeAbstract
{
QGraphisWidget* getTheme();
}
In this case the theme for Task popups would do the rendering of the
preview and window stuff.
The ToolTipManager call would remain the same only the values would be
different.
Plasma::ToolTipManager::self()-setContent(QGraphicsWidget,
ToolTipThemeAbstract);
The ToolTipManager would simply render the theme (getTheme()). I'm not
quite sure yet if the data can just be put directly in the theme or if the
theme and data should be separated.
Also, some themes should probably be provided by default. For example
the TasksAppLauncher theme like in the ascii art above seems like a quite
common fancy tooltip. Other themes like the dolphin one should just be an
in house theme in the dolphin codebase. Others might like it, but it's
certainly not a default theme that needs to be provided or something.
I think this would cleanup the ToolTip mess quite a bit and make it very
flexible for everyone to use.
I will try and make a proof of concept for this in the coming days.
Don't count on anything though - just to prevent high hopes.
If this works out and is going to be used for KDE then i would like to
deprecate the current ToolTip and friend classes, delete them in frameworks
and replace everything by this proposed tooltip structure.
Please do let me know what your thoughts are about this one!
Cheers,
Mark
[1] Right now i'm fixing the blur issue for Dolphin and System Settings.
Those patches will appear on reviewboard somewhere tomorrow.
Lol, no theme then I write theme about everywhere.. I obviously meant
style! Though template might fit the meaning better.
Sorry,
Mark
Patches for:
Dolphin: https://git.reviewboard.kde.org/r/105061/
System Settings: https://git.reviewboard.kde.org/r/105060/
I'd like to push them to master before the 4.9 branch happens. Why? because
i see this as - long standing - bugs being fixed.
Also, this fixes the current situation that the most common tooltips are at
least consistent in blurring.. It's obviously a temporary fix. The real fix
would require a lot more work as you can read in my first post in this
thread.
Cheers,
Mark
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The tooltip state. Not that good. Proposal for improvement.
Op 26 mei 2012 03:08 schreef Mark mark...@gmail.com het volgende:
Hi,
While trying to fix some blur issues on tooltips i found myself digging
deeper in ... other issues.
For starters, there is no tooltip consistency!
- Dolphin uses it's own tooltip classes.
- System Settings uses it's own tooltip classes.
- The plasma panels use the Plasma::ToolTipManager class - like it should
be!
That's only for the consistency using classes! The style also differs and
only the last one has blur behind it [1].
For dolphin i can understand the reason to have it's own tooltip class
because it wants to fetch the tooltip data in a separate process in order
to prevent a crash in the tooltip from crashing dolphin.
To get this in a workable situation where anyone can use the tooltips as
they seem right we probably have to make a new ToolTipManager altogether.
The current one is _way_ to much tailored at tooltips for the tasks
plasmoid and doesn't leave much room for customization (correct me if i'm
wrong). I would like to suggest a ToolTipManager with styles! Not themes! I
repeat, not themes! Just style as in which data is being displayed where.
The plasma theme is still the one to be for the theme so nothing changes
there. What i think that should be possible is defining a ToolTip Theme. Or
i actually think it's required if the plasma tooltip stuff is to be used in
places where the tooltip can look completely different (again, like
dolphin).
For example (in ascii art).
ToolTipTheme - Dolphin
|---| test...
|ICON|
|---| test...
text...
ToolTipTheme - TasksAppLauncher
|---| APP NAME
|ICON| APP DESCRIPTION
|---|
ToolTipTheme - TasksPopup
|--|
|--|
|--|
|--|
|--|
|--|
|---|
|ICON| APP DESCRIPTION
|---|
That should make the intention clear even though the ascii art sucks ;)
I would say that we need an abstract theme class:
class ToolTipThemeAbstract
{
virtual QGraphisWidget* getTheme() = 0;
}
and some classes that implement it:
class ToolTipThemeDolphin : public ToolTipThemeAbstract
{
QGraphisWidget* getTheme();
}
In this case the theme for Task popups would do the rendering of the
preview and window stuff.
The ToolTipManager call would remain the same only the values would be
different.
Plasma::ToolTipManager::self()-setContent(QGraphicsWidget,
ToolTipThemeAbstract);
The ToolTipManager would simply render the theme (getTheme()). I'm not
quite sure yet if the data can just be put directly in the theme or if the
theme and data should be separated.
Also, some themes should probably be provided by default. For example
the TasksAppLauncher theme like in the ascii art above seems like a quite
common fancy tooltip. Other themes like the dolphin one should just be an
in house theme in the dolphin codebase. Others might like it, but it's
certainly not a default theme that needs to be provided or something.
I think this would cleanup the ToolTip mess quite a bit and make it very
flexible for everyone to use.
I will try and make a proof of concept for this in the coming days. Don't
count on anything though - just to prevent high hopes.
If this works out and is going to be used for KDE then i would like to
deprecate the current ToolTip and friend classes, delete them in frameworks
and replace everything by this proposed tooltip structure.
Please do let me know what your thoughts are about this one!
Cheers,
Mark
[1] Right now i'm fixing the blur issue for Dolphin and System Settings.
Those patches will appear on reviewboard somewhere tomorrow.
Lol, no theme then I write theme about everywhere.. I obviously meant
style! Though template might fit the meaning better.
Sorry,
Mark
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
