[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: VFolders isn't a standard yet


> This VFolders stuff seems needlessly complicated and overly ambitious.
> It tries to solve problems that aren't really much of a problem on
> most people's desktops (50 xeyes?) and it does this by trashing the
> simple and well-accepted concept[2] of fs-based hierarchical menus
> that both GNOME and KDE have successfully implemented and deployed.[1]

In an corporate environment, something that both GNOME and KDE [to my
limited knowledge] have't ever really thought about up until now, the
heirarchical menu scheme doesn't really scale all that well.

> It seems to be a matter of adding bloat to solve a problem that could
> be solved by preserving the current solution (still supported by
> GNOME2 I assume, so not a problem), a little care[3], and
> standardising or correcting the right things[4].

I would hardly called the addition of a standard location for .desktop
files bloat, nor, for that matter, the addition of a new 'Categories'
key in the .desktop file and consequent possible values.

The backend to parse this information has always been up to the
individual desktop to develop, in GNOME's case using gnome-vfs and the
.vfolder-info file.

> Furthermore, I see no evidence that this proposal is being pushed or
> has been explicitly approved by the relevant KDE maintainers (I see a
> couple of side comments in the archives), though I note Red Hat's
> enthusiasm.  The proposal was described as being only a slight
> extension at some point, so perhaps the right people didn't pay proper
> attention?

Yes, this is unfortunate but you can't say that there wasn't opportunity
to give feedback since it was posted on an open list.

> [2] Look at how much documentation and hand-holding GNOME2 users are
>     needing currently.

This is a little bit unfair. GNOME 2 currently lacks UI support for menu
editing, a regretable feature that we simply had not time to develop
before the release. As a result, it was neccessary to disable normal
'user' level menu editing and write a document for the more advanced
user/sytem administrator. This was all done at the last moment.

> [1] And probably, Windows, the desktop with the biggest market-share
>     in the world does this too.  I know that's not the best
>     example but Windows is in fact the desktop with the most 3rd-party
>     apps and, ostensibly, they maintain their menus just fine.
>     Suddenly, Linux has a problem with the menu directory hierarchy?

Windows maintaining their menus just fine? You are kidding, right? :/

> [4] Some of which, such as the list of Categories, can be taken from
>     the VFolders proposal. Perhaps a thing or two could be learned
>     from Windows 3rd party installers as well, ie perhaps the problem
>     could be adequately solved in the package manager/installer (RPM
>     mostly, dpkg seems to have it down pat).

Let me repeat, the vfolder spec *only* contains 2 things -

	a) agreement on a standard location for .desktop files
	b) addition of the 'Categories' key in the .desktop file and
	   suitable values for this key.

				See ya,
					Glynn ;)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]