From: PCMan <pcm...@gm...> - 2010-08-08 21:20:44
|
Hi list, After finishing LXAppearance2, now it's time to give some love to the most problematic component, the file manager. Today I carefully reviewed the whole bug tracker and user-feed backs in my mailbox and thought about how to continue. The final decision is, the release of 1.0 needs to be postpond because it's not yet ready. In addition, I'd like to unfreeze the UI and strings. It's not possible to fix some bugs without modifying the strings. Some new strings should be added for error reporting or something similar. Moreover, it's not possible to fix several significant usability bugs and design defects without doing some small modifications to the UI. If there is no objection, I'm going to unfreeze pcmanfm and libfm and do my best to fix all the issues. I'll try to keep the newly added strings and UI changes as fewer as possible. The date pf 1.0 is not yet decided, but it will be near the end of 2010. Yes, it's possible that Lubuntu 10.10 may not be able to ship the final stable release. However, for an application frequently used everyday, the quality must be better. I won't break backward compatability in the coming month. Everything should just work as usual or better. Anyway, I'm going to do this in a branch first. Later if things are ok, merge it with master branch. So nothing in current repo will be broken. Thank you for all the support! |
From: Marty J. <mar...@co...> - 2010-08-09 11:38:15
|
If there is one thing that comes up again and again in the forum about the file manager, it is the request to be able to reposition icons on the desktop and have them stay where they are put. I hope you are planning to implement that if it is not yet done. On 08/08/2010 05:20 PM, PCMan wrote: > Hi list, > After finishing LXAppearance2, now it's time to give some love to the > most problematic component, the file manager. > Today I carefully reviewed the whole bug tracker and user-feed backs > in my mailbox and thought about how to continue. > The final decision is, the release of 1.0 needs to be postpond because > it's not yet ready. > In addition, I'd like to unfreeze the UI and strings. It's not > possible to fix some bugs without modifying the strings. > Some new strings should be added for error reporting or something similar. > Moreover, it's not possible to fix several significant usability bugs > and design defects without doing some small modifications to the UI. > If there is no objection, I'm going to unfreeze pcmanfm and libfm and > do my best to fix all the issues. > I'll try to keep the newly added strings and UI changes as fewer as possible. > The date pf 1.0 is not yet decided, but it will be near the end of 2010. > Yes, it's possible that Lubuntu 10.10 may not be able to ship the > final stable release. > However, for an application frequently used everyday, the quality must > be better. > I won't break backward compatability in the coming month. Everything > should just work as usual or better. > Anyway, I'm going to do this in a branch first. Later if things are > ok, merge it with master branch. > So nothing in current repo will be broken. > > Thank you for all the support! > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Christoph W. <chr...@go...> - 2010-08-10 10:04:43
|
Am Montag, den 09.08.2010, 07:38 -0400 schrieb Marty Jack: > If there is one thing that comes up again and again in the forum about > the file manager, it is the request to be able to reposition icons on > the desktop and have them stay where they are put. I hope you are > planning to implement that if it is not yet done. I think the tree view is way more important. It used to exist in the old pcmanfm so it is a regression while free positioning of icons is just a feature request. Regards, Christoph |
From: Neil G. <Le...@sc...> - 2010-08-11 19:50:21
|
On Mon, 09 Aug 2010 07:38:08 -0400, Marty Jack wrote: > If there is one thing that comes up again and again in the forum about > the file manager, it is the request to be able to reposition icons on > the desktop and have them stay where they are put. I hope you are > planning to implement that if it is not yet done. > I have been wandering through the pfmanfm code myself with an eye towards contributing something to do this. At the very least some ideas. Moving Icons to different positions should be a relatively simple task, The tricky bit is making those positions persistent. You have to store the data somewhere. It seems there is no standard mechanism for storing icon positions. I have files such as ~/.config/xfce4/desktop/icons.screen0.rc which are fairly obvious. ROX-Filer has its pinboards which makes things easy for itself because it doesn't use the ~/Desktop Directory. KDE and Gnome presumably have their own cryptic methods for storing positions. I would advocate a hidden file in the Desktop directory itself, in a nice simple text format. Perhaps just a little more sophisticated than the xfce form. xfce uses. [silly_walks.jpg] row=1 col=2 [Home] row=1 col=1 My preference is for totally free moving icons, so I'd have just X and Y and have griding at a higher level if chosen. What would be nice is if the X and Y could be relative either side or proportional to desktop size So perhaps [silly_walks.jpg] X = 120 Y =-150 [Home] X = 50% Y = 10% Which could represent an icon 120 pixels from the left and 150 from the bottom of the workspace, and an Icon in the middle near the top. That would be quite easy to manage at runtime (user interface to select what is desired more complex) and would mean resizing the display wouldn't necessarily screw up all your icons. .. and a completely offtopic tangent. Does LXDE need a desktop widget engine? 'cos I wrote one and it's looking for a home. :-) |
From: Martin B. / b. <br...@bs...> - 2010-08-11 20:04:17
|
On Wed, 11 Aug 2010, Neil Graham wrote: > So perhaps > [silly_walks.jpg] > X = 120 > Y =-150 > Which could represent an icon 120 pixels from the left and 150 from the > bottom of the workspace, and an Icon in the middle near the top. um. isn't 0,0 usually in the top right corner? This might be my lack of X11 knowledge speaking =) And I know that this is nothing important, the detail struck me =) -- /brother http://martin.bagge.nu Bruce Schneier's discrete logarithms are uncountable and continuous |
From: Marty J. <mar...@co...> - 2010-08-11 20:14:19
|
(0,0) is the upper left corner of whatever virtual desktop (_NET_DESKTOP_VIEWPORT in the Compiz wall way of doing things) is currently visible, with x and y increasing to the right and down. A window can be at negative coordinates if it is on a virtual desktop that is to the left or above what is visible. But not in the _NET_CURRENT_DESKTOP (Openbox desktop) sense; those windows are all at (0,0). That said, using negative numbers to mean "plus the width or height, minus this value" is an encoding you could live to regret. On 08/11/2010 04:04 PM, Martin Bagge / brother wrote: > On Wed, 11 Aug 2010, Neil Graham wrote: > >> So perhaps >> [silly_walks.jpg] >> X = 120 >> Y =-150 >> Which could represent an icon 120 pixels from the left and 150 from the >> bottom of the workspace, and an Icon in the middle near the top. > > um. isn't 0,0 usually in the top right corner? This might be my lack of > X11 knowledge speaking =) > And I know that this is nothing important, the detail struck me =) > |
From: Alessandro P. <al...@am...> - 2010-08-12 07:44:36
|
Il giorno mer, 11/08/2010 alle 20.47 +0000, Neil Graham ha scritto: > An alternative is to use Top,Bottom,Left,Right instead of X and Y. But > you then have to do decide what happens if Top _and_ Bottom or Left _and_ > right are specified. Why not go the whole way and make it css-style? :) silly-walks.jpg { left: 10px; right: 100px; top: 50%; bottom: 20%; width: 64px; height: 64px; background-color: #aaa; } right would "overwrite" left becaus it comes after it, and bottom overwrites top for the same reason. bottom: 20% means (as in Gtk) "the point 20% from bottom of the image shold be 20% from the bottom of the screen". This way writing left:50%;top:50%; places the image at the very center of the screen (and not shifted down and right). It is extendable, so if you want (in the future) to implement a rounded box you can add border-radius: 5px; border-color: #000; border-width: 1px; Maybe a little bit overkill for placing icons, but it could be used for the whole styling, as gnome is doing, so maybe one day it will be integrated in gtk+. Bye. |
From: Marty J. <mar...@co...> - 2010-08-12 10:50:59
|
That's the cleanest idea about how to do this I've seen in a long while. Make it like css but be very selective about how many knobs to have. I like it a lot. On 08/12/2010 03:44 AM, Alessandro Pellizzari wrote: > Il giorno mer, 11/08/2010 alle 20.47 +0000, Neil Graham ha scritto: > >> An alternative is to use Top,Bottom,Left,Right instead of X and Y. But >> you then have to do decide what happens if Top _and_ Bottom or Left _and_ >> right are specified. > > Why not go the whole way and make it css-style? :) > > silly-walks.jpg > { > left: 10px; > right: 100px; > top: 50%; > bottom: 20%; > width: 64px; > height: 64px; > background-color: #aaa; > } > > right would "overwrite" left becaus it comes after it, and bottom > overwrites top for the same reason. > > bottom: 20% means (as in Gtk) "the point 20% from bottom of the image > shold be 20% from the bottom of the screen". This way writing > left:50%;top:50%; places the image at the very center of the screen (and > not shifted down and right). > > It is extendable, so if you want (in the future) to implement a rounded > box you can add > > border-radius: 5px; > border-color: #000; > border-width: 1px; > > Maybe a little bit overkill for placing icons, but it could be used for > the whole styling, as gnome is doing, so maybe one day it will be > integrated in gtk+. > > Bye. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: TOM T. <tho...@gm...> - 2010-08-13 15:37:37
|
Hi everyone. I felt I should point out that having icons show on the desktop the way gnome,xfce,windows etc do often results in cluttered, ugly and impractical desktop experience. KDE4 seems to have found a way around it with plasma desktop, but still maybe there's a better solution. since you're thinking of implementing it, why not innovate? 2010/8/13 PCMan <pcm...@gm...> > This one is my original plan. > However the problem is not how to store it. > This is easy. > The problem is how to handle the UI part. > If you sort items by name, how should a item with custom position behave? > If you have a newly added item, where should it be placed? > If the screen gets resized, how should the icons be placed? > If the font or icon sizes get changed, how should the icons be placed? > If we want to add icons for newly added devices, where should they be > placed? > I thought of these problems for quite a long time, and haven't found a > better way to do it yet. > These UI problems are not going to be solved either by GKeyFile or css. > > Any suggestions? > > On Fri, Aug 13, 2010 at 8:30 AM, Neil Graham <Le...@sc...> > wrote: > > On Thu, 12 Aug 2010 06:50:52 -0400, Marty Jack wrote: > > > >> That's the cleanest idea about how to do this I've seen in a long while. > >> Make it like css but be very selective about how many knobs to have. I > >> like it a lot. > > > > In that case I would recommend going with > > > > [silly-walks.jpg] > > left=10px > > right=100px > > top=50% > > bottom=20% > > width=64px > > height=64px > > background-color=#aaa > > > > Which would work with > http://library.gnome.org/devel/glib/stable/glib-Key- > > value-file-parser.html > > > > Which pcmanfm already uses. > > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by > > > > Make an app they can't live without > > Enter the BlackBerry Developer Challenge > > http://p.sf.net/sfu/RIM-dev2dev > > _______________________________________________ > > Lxde-list mailing list > > Lxd...@li... > > https://lists.sourceforge.net/lists/listinfo/lxde-list > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Neil G. <Le...@sc...> - 2010-08-11 20:48:12
|
On Wed, 11 Aug 2010 16:14:13 -0400, Marty Jack wrote: > That said, using negative numbers to mean "plus the width or height, > minus this value" is an encoding you could live to regret. > An alternative is to use Top,Bottom,Left,Right instead of X and Y. But you then have to do decide what happens if Top _and_ Bottom or Left _and_ right are specified. That which does not kill us, has made its last mistake. |
From: Marty J. <mar...@co...> - 2010-08-11 20:57:29
|
Doesn't sound any more challenging than deciding what happens if the screen has been resized small enough that the top-relative and bottom-relative specifications start to collide. Having the screen resize or a monitor disappear in between starts of the system is a real pain. You have to do something sensible to make sure most of what was configured is still visible somewhere, or its control knobs at least accessible from what is left, so you can reconfigure it onto a visible screen or delete it. This did not work well with having the only way to get to a panel's configuration dialog be from right-clicking on that panel. On 08/11/2010 04:47 PM, Neil Graham wrote: > On Wed, 11 Aug 2010 16:14:13 -0400, Marty Jack wrote: >> That said, using negative numbers to mean "plus the width or height, >> minus this value" is an encoding you could live to regret. >> > An alternative is to use Top,Bottom,Left,Right instead of X and Y. But > you then have to do decide what happens if Top _and_ Bottom or Left _and_ > right are specified. > > > That which does not kill us, has made its last mistake. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Neil G. <Le...@sc...> - 2010-08-13 00:31:20
|
On Thu, 12 Aug 2010 06:50:52 -0400, Marty Jack wrote: > That's the cleanest idea about how to do this I've seen in a long while. > Make it like css but be very selective about how many knobs to have. I > like it a lot. In that case I would recommend going with [silly-walks.jpg] left=10px right=100px top=50% bottom=20% width=64px height=64px background-color=#aaa Which would work with http://library.gnome.org/devel/glib/stable/glib-Key- value-file-parser.html Which pcmanfm already uses. |
From: PCMan <pcm...@gm...> - 2010-08-13 14:51:17
|
This one is my original plan. However the problem is not how to store it. This is easy. The problem is how to handle the UI part. If you sort items by name, how should a item with custom position behave? If you have a newly added item, where should it be placed? If the screen gets resized, how should the icons be placed? If the font or icon sizes get changed, how should the icons be placed? If we want to add icons for newly added devices, where should they be placed? I thought of these problems for quite a long time, and haven't found a better way to do it yet. These UI problems are not going to be solved either by GKeyFile or css. Any suggestions? On Fri, Aug 13, 2010 at 8:30 AM, Neil Graham <Le...@sc...> wrote: > On Thu, 12 Aug 2010 06:50:52 -0400, Marty Jack wrote: > >> That's the cleanest idea about how to do this I've seen in a long while. >> Make it like css but be very selective about how many knobs to have. I >> like it a lot. > > In that case I would recommend going with > > [silly-walks.jpg] > left=10px > right=100px > top=50% > bottom=20% > width=64px > height=64px > background-color=#aaa > > Which would work with http://library.gnome.org/devel/glib/stable/glib-Key- > value-file-parser.html > > Which pcmanfm already uses. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Andrea F. <an...@op...> - 2010-08-13 15:17:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 13/08/2010 16:51, PCMan ha scritto: > This one is my original plan. > However the problem is not how to store it. > This is easy. > The problem is how to handle the UI part. > If you sort items by name, how should a item with custom position behave? for what i saw on all the other file managers (including windows) if you choose to sort, you just sort, custom positions are reset and all files are sorted from left to right and from top to bottom: (like in this rought example) 1 4 2 5 3 6 > If you have a newly added item, where should it be placed? nautilus add it in the first available position (according to the previous scheme) > If the screen gets resized, how should the icons be placed? > If the font or icon sizes get changed, how should the icons be placed? > If we want to add icons for newly added devices, where should they be placed? > I thought of these problems for quite a long time, and haven't found a > better way to do it yet. > These UI problems are not going to be solved either by GKeyFile or css. > > Any suggestions? aside for the few i wrote, why don't just check of others do and we do it in the same way? - -- - ------------------------------------------ Andrea Florio QSI International School of Brindisi Sys Admin CISCO CCNA Certified openSUSE-Education Administrator openSUSE-LXDE Administrator openSUSE Official Member (anubisg1) Email: an...@op... Packman Packaging Team Email: an...@li... Cell: +39-328-7365667 - ------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlYyoACgkQyCZT87TFPug1ogCgrqr9LC7X/OSCIwUzdSV5l3zr xHUAoJ2T3G+cgidBlLM/oGsL+QmZGrfv =Jsw2 -----END PGP SIGNATURE----- |
From: Andrea F. <an...@op...> - 2010-08-13 16:02:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 13/08/2010 17:37, TOM TOM ha scritto: > Hi everyone. > > I felt I should point out that having icons show on the desktop the way > gnome,xfce,windows etc do > > often results in cluttered, ugly and impractical desktop experience. > > KDE4 seems to have found a way around it with plasma desktop, but still > maybe there's a better solution. > > since you're thinking of implementing it, why not innovate? > > i'm sorry but i don't really agree... i know several people (including me) that hate the kde4 way, and has been "pushed" to others DE like gnome, when they really loved kde3). The reason that any way, no other DE is doing it, and the thing that not even windows (that even if we don't like is anyway the most used OS) chosed a similar way to work with the desktop, is IMHO something the confirm my theory.. kde4 plasma desktop can even be something really revolutionary, but we are not ready (or we don't want it) for that yet. just my 2 cents Andrea - -- - ------------------------------------------ Andrea Florio QSI International School of Brindisi Sys Admin CISCO CCNA Certified openSUSE-Education Administrator openSUSE-LXDE Administrator openSUSE Official Member (anubisg1) Email: an...@op... Packman Packaging Team Email: an...@li... Cell: +39-328-7365667 - ------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlbYQACgkQyCZT87TFPuhDkwCZASfh1pvwnSW8kIBk/jNhg1QK MA8An2dcsczMJ32LbHC+RE/fmUdBG85g =FpRn -----END PGP SIGNATURE----- |
From: PCMan <pcm...@gm...> - 2010-08-13 18:32:19
|
OK, I describe my idea more clearly. I want to make some desktop items stick on the same position regardless how the user sorts the items. So no matter how you sort the items, some items can still stay at the position you specified. Previously I want to make this fully available in the UI. Now, I think I should do it in the config file first. I can solve the UI later, but at least placing desktop items should be enabled in config files. So at least it's as good as something like idesks. When the Dnd part of libfm is improved, we can make this fully working in the UI. This week I'm working on a new implementation of dir tree in the side pane. However I'm very busy this week and was not able to finish it in time. Later I'll make placing the desktop items available from config file first. Thanks On Sat, Aug 14, 2010 at 12:06 AM, Andrea Florio <an...@op...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Il 13/08/2010 17:37, TOM TOM ha scritto: >> Hi everyone. >> >> I felt I should point out that having icons show on the desktop the way >> gnome,xfce,windows etc do >> >> often results in cluttered, ugly and impractical desktop experience. >> >> KDE4 seems to have found a way around it with plasma desktop, but still >> maybe there's a better solution. >> >> since you're thinking of implementing it, why not innovate? >> >> > > i'm sorry but i don't really agree... > i know several people (including me) that hate the kde4 way, and has > been "pushed" to others DE like gnome, when they really loved kde3). The > reason that any way, no other DE is doing it, and the thing that not > even windows (that even if we don't like is anyway the most used OS) > chosed a similar way to work with the desktop, is IMHO something the > confirm my theory.. kde4 plasma desktop can even be something really > revolutionary, but we are not ready (or we don't want it) for that yet. > > just my 2 cents > Andrea > > - -- > - ------------------------------------------ > Andrea Florio > QSI International School of Brindisi Sys Admin > CISCO CCNA Certified > openSUSE-Education Administrator > openSUSE-LXDE Administrator > openSUSE Official Member (anubisg1) > Email: an...@op... > Packman Packaging Team > Email: an...@li... > Cell: +39-328-7365667 > - ------------------------------------------ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.15 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxlbYQACgkQyCZT87TFPuhDkwCZASfh1pvwnSW8kIBk/jNhg1QK > MA8An2dcsczMJ32LbHC+RE/fmUdBG85g > =FpRn > -----END PGP SIGNATURE----- > |
From: Neil G. <Le...@sc...> - 2010-08-14 01:26:06
|
On Fri, 13 Aug 2010 18:37:27 +0300, TOM TOM wrote: > KDE4 seems to have found a way around it with plasma desktop, but still > maybe there's a better solution. > > since you're thinking of implementing it, why not innovate? I think there is space for experimentation but I don't think I'd want it to be part of pcmanfm. Trying new ideas is inherently risky and shouldn't be foisted upon people who have made their decision to use pcmanfm based upon the things it currently does. I think pcmanfm does all it needs to support desktop systems which are a significant departure of the current field. It has the option to not manage the desktop and let something else do it. Develop the innovative systems as standalone programs and incorporate the designs that work well at a later date. Having said that. I have been idly considering making such a standalone 'desktop' using a pop-out radial system. http://screamingduck.fileburst.com/Cruft/WidgetClosed.jpg http://screamingduck.fileburst.com/Cruft/WidgetOpen.jpg Who knows I may actually even write it :-) |
From: Alessandro P. <al...@am...> - 2010-08-14 09:33:54
|
Il giorno ven, 13/08/2010 alle 22.51 +0800, PCMan ha scritto: > If you sort items by name, how should a item with custom position behave? Reset positions, as Andrea said. > If you have a newly added item, where should it be placed? In the first free spot. You should define square spots and check the first completely free. Then it becomes a custom icon and gets saved in the config file. Next time it will appear in the same spot. > If the screen gets resized, how should the icons be placed? if the icon fits on the screen, maintain its custom position, else reset it and place in the first free spot. > If the font or icon sizes get changed, how should the icons be placed? The font should be irrelevant, just place it centered under the icon. If the icon size changes it becomes a custom icon, and has a width and height associated. > If we want to add icons for newly added devices, where should they be placed? In the first available spot. In the end, a lot of cases fall back to "newly added item". Bye. |
From: <u-l...@ae...> - 2010-08-14 10:43:14
|
Hi Alessandro, On Sat, Aug 14, 2010 at 11:33:09AM +0200, Alessandro Pellizzari wrote: > > If the screen gets resized, how should the icons be placed? > > if the icon fits on the screen, maintain its custom position, else reset > it and place in the first free spot. Not that simple. I do not want to lose my chosen icon placement just because I happened to log in once on a small screen or chose to reduce the screen size for a moment. On the other side, I can live with the mandatory placement which LXDE has for the moment :) Note though that your proposed behaviour could become frustrating if I begin to use the new functionality and expect to find my icons where I left them. Regards, Rune |
From: PCMan <pcm...@gm...> - 2010-08-14 17:32:12
|
On Sat, Aug 14, 2010 at 5:33 PM, Alessandro Pellizzari <al...@am...> wrote: > Il giorno ven, 13/08/2010 alle 22.51 +0800, PCMan ha scritto: > >> If you sort items by name, how should a item with custom position behave? > > Reset positions, as Andrea said. This can be annoying if, for example, you want to keep Trash Can at the right lower corner and sort others only. >> If you have a newly added item, where should it be placed? > > In the first free spot. You should define square spots and check the > first completely free. This doesn't work when you have too many files on the desktop. In addition, if you freely place the items at arbitrary position, there is no "free slot". > Then it becomes a custom icon and gets saved in the config file. Next > time it will appear in the same spot. > >> If the screen gets resized, how should the icons be placed? > > if the icon fits on the screen, maintain its custom position, else reset > it and place in the first free spot. I don't agree. In this way you loss all the placement if you login with a different screen size. Even worse, if you change the size of desktop panel, this affect the size of working area. So you loss the placement of all icons. >> If the font or icon sizes get changed, how should the icons be placed? > > The font should be irrelevant, just place it centered under the icon. > If the icon size changes it becomes a custom icon, and has a width and > height associated. No, if you use larger font, fixed size and position will make the icon text totally unreadable. >> If we want to add icons for newly added devices, where should they be placed? > > In the first available spot. > > In the end, a lot of cases fall back to "newly added item". > > Bye. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Alessandro P. <al...@am...> - 2010-08-15 05:11:56
|
Il giorno dom, 15/08/2010 alle 01.32 +0800, PCMan ha scritto: > On Sat, Aug 14, 2010 at 5:33 PM, Alessandro Pellizzari <al...@am...> wrote: > > Il giorno ven, 13/08/2010 alle 22.51 +0800, PCMan ha scritto: > > > >> If you sort items by name, how should a item with custom position behave? > > > > Reset positions, as Andrea said. > This can be annoying if, for example, you want to keep Trash Can at > the right lower corner and sort others only. The Trashcan would have "right" and "bottom" instead of "top" and "left", so it will always fit on the screen. :) > >> If you have a newly added item, where should it be placed? > > > > In the first free spot. You should define square spots and check the > > first completely free. > This doesn't work when you have too many files on the desktop. > In addition, if you freely place the items at arbitrary position, > there is no "free slot". Then place them upper left, and the user will reposition them wherever he wants. If its desktop is crowded he will know the icons will overlap someday. > I don't agree. In this way you loss all the placement if you login > with a different screen size. Having right and bottom relative placement mitigates this. And even percent-based, see below. The true question is: how does the user visually see he is going to position relative to right and bottom? Maybe we could think of "hotspots" on the 4 screen edges. The user drags the icon on one of those hotspots, then continues dragging it to the final position. The icon will be relative to the visited hotspot. A (semitransparent) line could connect the hotspot to the icon while dragging, so the user knows which hotspot it is relative to, and the positions could be all percent-based, so all the icons will remain onscreen even when resizing screen. > Even worse, if you change the size of > desktop panel, this affect the size of working area. So you loss the > placement of all icons. The panel size would change only a small portion of the screen, so a few icons would be affected. The others would remain in their places. But again: using percent-based positions would avoid the problem. The size also could be percent-based, so the icon would never overlap, but simply get smaller or bigger if you resize the screen. This would be great for svg icons, but could ruin pixel-based ones. > No, if you use larger font, fixed size and position will make the icon > text totally unreadable. I don't think I understand correctly. The text should not be as large as the icon, but expand left and right, so just define "how much left and right" (for example, the icon is 64x64 pixels, the text could be 192 pixels large (64+64+64) and 64 pixels high. Everithing exceeding that would get cropped and ellipsized. Hovering the icon could show the whole text if it got cropped. This way you know that if your "typical icon" is 64x64, your slots would be 192x128, to accomodate the icon and the text below. |
From: Neil G. <Le...@sc...> - 2010-08-14 22:38:13
|
On Sun, 15 Aug 2010 01:32:04 +0800, PCMan wrote: >> Reset positions, as Andrea said. > This can be annoying if, for example, you want to keep Trash Can at the > right lower corner and sort others only. Perhaps a Lock attribute. Doing any form of Arrange Icons Does not alter the position of Locked icons. This would also be a good option for systems which children use. >>> If you have a newly added item, where should it be placed? >> if the icon fits on the screen, maintain its custom position, else >> reset it and place in the first free spot. > I don't agree. In this way you loss all the placement if you login with > a different screen size. Even worse, if you change the size of desktop > panel, this affect the size of working area. So you loss the placement > of all icons. This would be mitigated by the percentage and Bottom/Right relative positioning, but could be improved even more by having Desired Position and Actual Position. Icons that have desired positions offscreen seek the nearest on-screen point (but remember when the screen size is changed to accommodate them). If Icons are impinging on the space of other icons you can push them apart. This is similar to a phase of Verlet integration used in games, you simply iterate several loops of shoving any icons that are overlapping apart. It would allow for no overlap and if the screen gets way too crowded they would pack in more tightly with as much overlap as is required. It's a process that is fast enough for games so should be fine for satisfying difficult Desktop layouts. As a pure coolness factor If you updated in realtime when dragging icons around, you'd never have the dragged icon over others because they'd move smoothly out of the way and return once the icon has passed. You'd have to lock folders though otherwise you wouldn't be able to drop an icon into a folder (although it would be pretty funny watching someone try) |