It would be fine to see some recent apps next to favourites, like it is made in Windows Start Menu
This should be really useful to merge favorites with recent. So favorites would be always stuck in recent.
Personally, I loathe merged favorites and recent. I know that some people prefer it, but I will only add it if I can come up with a way to make it support both ways.
One more tick to merge both of settings and variable that represents number of recent apps is simple and smart solution, isn't it? Also why the number of recent apps is hard coded to ten? Half of space is empty when i choose recent
Internally the code is a lot more complicated than that. Where it saves things, the objects internally that track favorites and recent, etc. How to expose it in the settings interface is not a problem. :) Recent is not hardcoded to 10 items in git. I have not yet released a stable version with the setting for selecting the amount of recent items.
(In reply to Graeme Gott from comment #4) So Favorites can't just be rendered atop of Recent in Recent category, while Foverites hidden?
I can show both the favorites and recent GtkTreeView widgets at the same time, sure, but it looks a little strange. They have separate GtkTreeModels and there is empty space at the bottom of the favorites (or a scroll bar if there are too many to fit, and that looks really odd).
(In reply to Graeme Gott from comment #6) Can't Recent GtkTreeModels be populated by Favorites first in case if option is selected?
(In reply to Graeme Gott from comment #4) > Recent is not hardcoded to 10 items in git. I have not yet released a stable > version with the setting for selecting the amount of recent items. Isn't 1.5.0 already has it? It seem to work.
@coth Oh, really, this setting has appeared in 1.5! I was inattentitive :)
(In reply to coth from comment #7) > (In reply to Graeme Gott from comment #6) > Can't Recent GtkTreeModels be populated by Favorites first in case if option > is selected? They would still be separate GtkTreeModels, though. As you added things to your Favorites, or ran new programs, they would become different. The Recent GtkTreeModel would push the favorites off the bottom as you ran new programs, and it wouldn't know about the favorites you add or remove.
If this is to be added, please make it optional, actually, I like the way it works now.
After trying several approaches, I have come to the conclusion that the only reasonable way to implement this is to have an option to show both GtkTreeViews. It does look a little odd when there are scrollbars, but at least it doesn't break things.
If optionally on, why not to have a third treeview populated separately? With a simple separator between favorites, at top, and recently used.
The code for populating the favorites and recent are part of the favorites and recent treeviews, and splitting that out makes the code quite messy and buggy. Also, favorites allows drag-and-drop and sorting and recent does not, so how would the third treeview handle that?
(In reply to Graeme Gott from comment #14) > The code for populating the favorites and recent are part of the favorites > and recent treeviews, and splitting that out makes the code quite messy and > buggy. Also, favorites allows drag-and-drop and sorting and recent does not, > so how would the third treeview handle that? Well, i'm not familiar with GTK and C, but with Delphi VCL/Lazarus LCL and its bastard brother .Net Windows Forms you can simply check whatever drag ends up below separator, and if so, you can simply disaccept it.
(In reply to coth from comment #15) > Well, i'm not familiar with GTK and C, but with Delphi VCL/Lazarus LCL and > its bastard brother .Net Windows Forms you can simply check whatever drag > ends up below separator, and if so, you can simply disaccept it. It's more complicated than that. The code that populates and maintains the favorites and recent is separate, and not compatible with each other, and not abstracted to manage other GtkTreeModels. Making it so would require rewriting the guts of Whisker Menu, which I will *not* do. Will you use this feature if they are stacked listviews? If not, there is no point in me merging the code I have already written to handle that. It is either stacked, or not at all.
Not sure i understand what you mean by stacked listview.
Created attachment 6750 stacked listview preview The favorites are on top, and the recently used are on bottom. Stacked listviews as in vertically stacked--one above the other.
Sounds good, can you post screenshot please?
ah, well. doesn't look nice, honestly. it won't be scrollable, so recent list will be difficult to use.
Created attachment 6751 stacked listview with label preview The recent and favorites are both scrollable. They each have their own scrollbar, so they are just as usable as they are right now. It does look a little strange, so I tried adding a label above the recently used. How about now?
well, the main problem is that favorites takes too much space and recent is in very little window.
(In reply to coth from comment #22) > well, the main problem is that favorites takes too much space and recent is > in very little window. Recent and favorites are the exact same size. It's an optical illusion if they don't look the same height; possibly from the scrollbar next to recent, or maybe because recent is the listview on the bottom.
That's the problem. Recent usually much longer than favorites. Usually i have 4-6 favorites and 10-14 recent. So this is really hard to use, as favorites won't scroll with recent. With dynamic height respectively of number of items inside it and optional remove of descriptions from favorites/recent could make it a bit better, but still not as good as on Windows 5.1-6.1.
Created attachment 6752 horizontal stacked listviews preview Okay, what about horizontally stacked listviews? Again, I am not willing to merge them, but I am trying to meet you halfway. FYI, you can already remove the descriptions.
I have changed the layout code and it is no longer possible to even have stacked listviews. Sorry, I don't see any way to support this.