-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    Linux42.org    OpenSkillz.com   
 
Home
Apps
Artwork
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login

-
- Group .- Group members (15) . 

Free Desktop Environment


other
technoshauntechnoshaun
GnoMenu - Documentatio n Manager
Description:

Base Specifications for the Free Desktop Environment

1. Any Desktop Environment needs a set of standards to determine the development path it will take. This specification is currently a rough draft of ideas and concepts. This is a beginning phase draft designed for interested parties to begin conception of a new Desktop Environment.

2. The following however, are base requirements for this DE:

Must follow and use all Open Desktop Specifications
Must use Compiz-Fusion for 3D, desktop effects and animations
Must use Emerald for theme Decorations
Must be OpenGL compliant
Must be user configurable to create the look, style and layout they desire
Must be user friendly but allow for advanced options for power users
Must not use any other Desktop Environment's tools and confguration applications
Development of tools to ease the creation of themes, including cursors and icons
Include integration with WINE using links to library files that handle the functions required to run the desired programs
Must fully Comply with Fitts' Law
Must be portable to work with any windowing system such as Xorg, Wayland, Xfree2k and others.

3. This DE needs to incorporate ideas and features found in Gnome, KDE, Xfce, LDE and all other DE environments used by *NIX systems. These features need to be properly evaluated for their usefulness and ability to enhance the Free Desktop Environment not just add features. If the feature does not add quality and desired ability then another solution or method needs to be utilized instead.

4. The DE must look at several sources for inspiration, ideas and concepts. Not only from DEs but from distribution specific implications of tools, layouts and designs as well.

Members:15
Comments:126
Created:May 23 2011
Changed:Jun 13 2011
Readability:readable for everybody
Membership:everybody can join

Invite people to join
Join group
Activate message notification



goto page: prev   1  2  3  4  5 

-
.

 Additions and Security

 
 by novomente on: Sep 3 2011  
Score 50%
novomentenovomente
Home

Maybe I have some solution on plugins and security issue.

Let's divide additions in File Manager to PLUGINS and ADDONS. While PLUGINS add new functionalities to the File Manager ADDONS only use and customize added functionalities. For example we have 2 PLUGINS. One adds a functionality of previewing OpenOffice.org documents, the second adds a functionality of previewing any kind of image file. Then we have an ADDON which customize File Manager the way it adds a sidebar showing a preview of selected file. The ADDON uses functionality of the 2 PLUGINS so it can show OpenOffice documents preview and image files preview.

PLUGINS:
- add new functionality
- is developed in a programming language like C, C++, JAVA or whatever we choose
- is installed with administrator rights
- can be installed through distro package manager

ADDONS:
- only customize and use functionality of File Manager and PLUGINS
- is written with something we decide (scripting languages, interpreted languages or whatever)
- is installed without administrator rights
- is installed through our new File Manager's PLUGINS and ADDONS Manager
- can or cannot depend on PLUGINS

PLUGINS and ADDONS Manager (I call it PA-Manager in this comment to shorten its name):
- adds PLUGINS and ADDONS to the File Manager
- is started separately (from File Manager's menu etc.) to leave a small memory trace when only browsing files and folders (and to start File Manager more quickly)

Security issue:
If there is only one user/administrator in Operating System he can easily install PLUGINS and ADDONS through PA-Manager (or PLUGINS through distro Package Manager or through command line). If There is multiuser OS installation (home, public library, institution or company etc.) then only the administrator has the right to decide which PLUGINS (functionality) are installed and users have the option to choose which PLUGINS will be allowed or disabled and what ADDONS will be installed and allowed/disabled. So administratos (public libraries, institutions, companies etc.) have the rights to decide what can be possible to do with File Manager and user (public library visitor, employee etc.) have the rights to customize it to his needs.

How PLUGINS and ADDONS Manager (PA-Manager) works:
In PA-Manager there is possibility to browse ADDONS (similar to Firefox) and browse PLUGINS through distro package management functionality implemented in PA-Manager. I think that PLUGINS will be browsed much less. When opening PA-Manager it can ask on administrator password for administrator rights. If the password is not typed the PA-Manager will work in user mode. In user mode there is no possibility to install PLUGINS but is possible to allow/disable PLUGINS and install and allow/disable ADDONS.

ADDONS can or cannot require installation of one or several PLUGINS (this is a decission an ADDON developer makes). There are two kinds of dependencies. One is that the dependend PLUGINs must be installed to function ADDON properly. The second is that ADDON require PLUGINS but can handle the situation when PLUGIN is not installed (ADDON can function properly without installing required PLUGINS). What kind of dependency will ADDON use is decided in ADDON's code for each PLUGIN by ADDON developer.

Imagine the two PLUGINS (OpenOffice documents preview and Any image file type preview) and one ADDON (preview sidebar) from the example mentioned above. The OpenOffice documents preview PLUGIN is installed while Any image file type preview PLUGIN is not. Assume that ADDON can handle this situation. So when selecting an OpenOffice document in the File Manager the ADDON will show its preview in a sidebar. When selecting an image file the ADDON shows in a sidebar for example a text saying it can't show a preview of this file type, or it can show only properties or icon of the file type, or whatever.

When installing an ADDON through the PA-Manager and user has administrator rights, the required PLUGINS are also installed. When the user has no administrator rights the ADDON is installed only if required PLUGINS are installed (mean only the PLUGINS which ADDON require to function properly). When ADDON is installed the PA-Manager will automaticaly allow disabled required PLUGINS. When ADDON is disabled PA-Manager will also disable those PLUGINS which are not used by allowed ADDONS. When allowing disabled ADDON the PA-Manager will also enable required PLUGINS.

On ADDONS web page (similar to Firefox Addon page) visible through PA-Manager can be shown informations about PLUGINS the ADDON require and also whether the PLUGINS were checked by Linux community and whether the PLUGIN is trusted to be secure. We can imagine to filter ADDONS using only trusted PLUGINS, disable installation of untrusted PLUGINS (and ADDONS using such PLUGINS) in PA-Manager etc.

That's the solution.


Reply to this

-

 Re: Additions and Security

 
 by Padster on: Sep 3 2011  
Score 50%
PadsterPadster
editor
Home

sounds good to me

101010
Reply to this

-

 Re: Additions and Security

 
 by MasKalamDug on: Sep 3 2011  
Score 50%
MasKalamDugMasKalamDug

This seems to me to be more an application of system administration theory than application design. In a single user environment all the add-ins have equal rights. In an administrated environment there are (at least) two different kinds of add-ins - system-wide and user-local. Each application (and I am interested in ALL applications - not just the File Manager) must begin by "installing" the user-specific add-ins (add-ons) before running the application proper.

But it seems that you are allowing local add-ins to use possible system add-ins that are not generally installed and these possible add-ins are made available. Hence it seems to follow that all the possible system add-ins are actually installed but some of them have been disabled by the administrator. When these are enabled to support a user add-in I assume they are enabled only to the user.

There are some situations - libraries, for example - where there is no continuity of user. That is, each user session is independent of all others. The user owns no files and so on. There are others where each physical computer is used by a single person but under administrative restrictions. And there are intermediate situations. But we must provide for user continuity (and zero it out when there is none). This means scanning each user's add-ins before running. The user add-in itself is somewhere out there in its own file and may be on a system wide list or something the user found somewhere.

So - each application should be accompanied by a set of separate add-in files differentiated most often by user log-in identity. The application starts by reading this file and enabling the add-ins identified there. In an administrated environment some. perhaps all, the administrator-installed add-ins can be disabled. The difference between plug-ins and add-ons seems to reduce to whether they are by default enabled or disabled.

I have postulated that an application is nothing but a wrapper around a collection of add-ins. But probably there should be one or more core add-ins which define the application. These, of course, cannot be disabled.

It is also implied that that each user has access to her add-in file for each application. A way to do this must be provided. There is already a means of getting some information about each file and a way to edit the add-ins probably belongs there. Since a single user wants to see none of the administrative machinery the fact that the add-in files are user-specific must be applied automatically.

Am I echoing your proposal fairly even though I have stated it in very different terms?


Reply to this

-

 Re: Re: Additions and Security

 
 by novomente on: Sep 3 2011  
Score 50%
novomentenovomente
Home

As I read your comments here you seem to be expirienced programmer. Since I am not well expirienced in programming (know only basics of few programming languages and have better knowledge in scripting and interpreted languages) I am glad you are here to make comments from a programmer's point of view.

I have read your comment slowly 2 times (my english is not perfect and I had to translate some words with a dictionary :) ). OK and I think I understand what you said. First thing is (maybe I missed something from the second article) I would like to say that system-wide add-ins (PLUGINS) disabled by administrator can't be used by user-local add-ins (ADDONS). This I meant to power the administrator with the right to decide what functionalities users can use.

To enable/disable system-wide add-ins by user I meant only for the purpose of starting the application more quickly and to leave less memory traces. Again I am not experienced programmer so this part is to discuss more by expirienced developers.

In your comment you said "an application is nothing but a wrapper around a collection of add-ins. But probably there should be one or more core add-ins which define the application. These, of course, cannot be disabled." I alway thought of application to have basic functionality implemented in it (not by core add-ins). But what you said is very interesting. I should improve my programming experience to talk to you more like a developer :).

"Since a single user wants to see none of the administrative machinery the fact that the add-in files are user-specific must be applied automatically." - if I understand it correctly then that's the thing to discuss by developers. What would be better. To let users to allow/disable system-wide add-ins or not (system-wide add-ins are allowed/disabled only by administrator). That must be think about. Make the application small, start quickly, less bugs, way of developing add-ins, how about cross application add-ins, universality of application, small app or rich app with many addins etc. etc. etc.


Reply to this

-

 Re: Re: Re: Additions and Security

 
 by MasKalamDug on: Sep 4 2011  
Score 50%
MasKalamDugMasKalamDug

I admit to being a native speaker of English and a longtime programmer

I read you wrong obviously about the relationship between plug-ins the administrator has disabled and user add-ons. I see no reason why any plug-ins the administrator does not want used are installed. There is no way to prevent a user from smuggling in a forbidden plug-in (perhaps after changing its name)

Here is my model again (a repeat may help):

I think of software in terms of object classes. An object class is code (and perhaps some associated fixed memory) that accepts and sends messages. An installed object class is one that is available on persistent storage. That is, there is an id and if I send the id to the file system the file system loads the code (and data) and tells me where to send the messages.

I think an application could be a script. It says load such-and-such an object. Most likely I also must send the object class some kind of a wake up message. That would be all there is in a simple application.

A simple application can send messages - but only to the operating system. If there are no other objects it can send messages only to the operating system but it must be able to receive messages from any other object.

Now consider an add-in. A first level add-in object would send messages to the core object (and get replies). Each nes object I add in gives me more possible messages. and so on.

Now it looks like I might need two application scripts - one for the system administrator and a local one that is specific to the logged-in user. The user should be able to see the administrator's script on a read-only basis. Until something suggests a more complicated set-up this is all I need. The application script could be as simple as nothing but a list of file identifiers (which should be thought of as URI's anyway). The core object surely needs a wakeup message and maybe the add-ins do to. So my script should be able to send messages (comparable to command lines).

Above I ignored the distinction between object class (code) and object instance (data) but I think what I mean is clear.


Reply to this

-

 Re: Re: Re: Re: Additions and Security

 
 by technoshaun on: Sep 4 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

I am sure we can set the install procedures so that only those with admin privileges can install plug ins. We can have that hard coded in to the file manager as well as what directory it looks for them in. In other words there are ways to keep non admins from fouling up the corporate control. Private desktop users have their admin rights so its a non issue there. Unlike Firefox we are looking to maintain certain levels of control so that while being flexible we also allow management level decisions to be maintained.
We maybe looking at using the Firefox methodology but not the trust level afforded to the average user. Admins must install the plug ins and add ons and end users can decide from those installed which to use, or not. I think we all agree to that and get going on drawing out the development map.

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-

 Re: Re: Re: Re: Re: Additions and Security

 
 by MasKalamDug on: Sep 5 2011  
Score 50%
MasKalamDugMasKalamDug

I would say that you have left no meaningful difference between plug-ins and add-ones. This way each application is accompanied by an add-in list and each user has her own subordinate file indicating which add-ins she is using. I imagine the master file to be able supply information about the plug-in and to carry indicators whether the plug-in is required, recommended or optional. So far as I can tell this is identical whether or not the system is administered. Is this, up to details, what you say is agreed upon?

Has any thought been given to how online help for using the add-ins is managed ?


Reply to this

-

 Re: Re: Re: Re: Re: Re: Additions and Security

 
 by technoshaun on: Sep 5 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

I am not disputing the differences between the two. What I'm trying to say is that the Firefox methodology of installing them is what we should use but you must have Admin level access to do so. We will discern the differences between plug-ins and add-ons in the development map. Does that make sense?

Honestly we can discuss this death and just spin around in circles or we can start the development map and move the project forward.

It isn't about it being free. Rather, its about the freedom it brings.

-

 Re: Re: Re: Re: Re: Re: Additions and Security

 
 by MasKalamDug on: Sep 5 2011  
Score 50%
MasKalamDugMasKalamDug

Old proverb - haste makes waste.

All I am trying to do is understand. Is there any difference in this scheme between plug-ins and add-ons ? If so, what ?

I don't think I am being stupid here. I learned a long time ago not to get involved in things I don't understand.



-

 Plug-Ins and Add-Ons

 
 by technoshaun on: Sep 5 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

Concerning the difference between the two I think Novomente gave a fairly well defined description which makes a lot of sense. While they are installed similarly they are not treated the same in how they are utilized by the File Manager. As he stated Add-Ons may require Plug-Ins, but Plug-Ins should rarely require a Add-On. Plug-Ins add functions to the File Manager, while Add-Ons install features for the end user. I think that is a good way to look at it and we should go with that.

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-

 Re: Plug-Ins and Add-Ons

 
 by MasKalamDug on: Sep 5 2011  
Score 50%
MasKalamDugMasKalamDug

I remain unenlightened. I am afraid I do not see any difference between a new function for the application and a new feature for the user nor any reason why they should be handled differently. All I can see is extensions of the application functionality.

Are you perhaps assuming two different ways to extend functionality? This strikes me as bad practice and an unnecessary piece of confusion.


Reply to this

-

 Re: Re: Plug-Ins and Add-Ons

 
 by technoshaun on: Sep 5 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

Plug-In = Back end with no to few user options
Add-On = Front end with user configurable options

I think this will help a bit on understanding what the difference is.

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-

 Re: Re: Re: Plug-Ins and Add-Ons

 
 by MasKalamDug on: Sep 5 2011  
Score 50%
MasKalamDugMasKalamDug

Assuming I understand you - I see two ends of a spectrum of possibilities rather than two different things. I think that it would be a mistake to force any improvement to one or the other end of the spectrum and a good design improvement to integrate them into a single syetem.

But that's just my opinion. Is this matter so integral to your overall design that it is forced one way or the other?


Reply to this

-

 Stripes DE look

 
 by technoshaun on: Sep 5 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

Take a look here for a new DE called Stripes. The developer shows some really good ideas concepts and design features well worth looking into http://personal.inet.fi/koti/mgimpl/stripes/

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-

 Plugins and Addons and Add-ins

 
 by novomente on: Sep 5 2011  
Score 50%
novomentenovomente
Home

I think that both of you are looking on the problem from a very different perspective and with different thoughts in your brain. So I comment it like this.

As a person with basics knowledge of programming I must say that giving anly administrators the power of installing both Plugins and Addons makes no difference between them from a developer point of view. As I understand it well then a plugin which adds functionalities to an application can be used by another plugin which adds or add not functionalities. The second plugin can be addon or another plugin.

The difference between plugin and addon I meant for a different security handling and ALSO for a different developing of them. While Plugin can be developed with a powerfull programming language the addon is written in more easy (for example scripting) language to allow less expirienced developers make addons.

But it seems that addons installed by user can be developed with the powerfull language (C, C++, etc.) too because when application runs plugin only the application (as a wrapper) allows the addon communicate with plugins and possibly the operating system.

Do I understand it correctly?

So by the solution I offered to discuss I was thinking on security issue and also development possibilities and usage of application and plugins and addons (or addins) or whatever we call it.


Reply to this

-

 must?

 
 by Digit on: Oct 15 2011  
Score 50%
DigitDigit
Home

sorry if this has been covered already.... but who came up with the list of musts in #2 there. was there a discussion and consensus formed, or is it more a decree from yet another benevolent dictator?

(sorry for jumping in like that... interesting idea, but seems rather stifling and rigid in that regard, so just had to ask.)

stay free. go gpl. ;)
Reply to this

-

 Re: must?

 
 by technoshaun on: Oct 15 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

Those are the rules for design and implementation of this DE. Yes I laid those out and will stand behind them, as they are simply necessary design decisions not dictatorship rules.

Must follow and use all Open Desktop Specifications
Since the Open Desktop Specifications are essentially the rules on how to interact with several things in *nix based desktops. This includes Icons and sounds it only makes sense to use this standard. It supports interoperability between DEs like Gnome and KDE. Kind of a big deal. All good DE designs follow this in *nix.

Must use Compiz-Fusion for 3D, desktop effects and animations
Must use Emerald for theme Decorations
Compiz is a windows manager, not a DE and using it as the base to build the DE saves us from reinventing the wheel. Since Emerald implements decoration for Compiz again saves us from rebuilding what's already available for use.

Must be OpenGL compliant
OpenGL is the video rendering engine used by nearly all *nix environments so again following the requirements for it is a sound decision.

Must be user configurable to create the look, style and layout they desire
Must be user friendly but allow for advanced options for power users
The whole point of this DE is to allow the end user to decide the what, where and how of the layout, operational aspects and feel of the desktop. This is the key part of the DE were discussing. The user gets final say in the layout. This is the main feature. Keeping it simple but not dumbed down is also a important feature. Power users should be allowed to have access to advanced controls.

Must not use any other Desktop Environment's tools and confguration applications
I.E. The tools and configuration apps needed for a DE should be built for this DE and not rely on those from other DEs. We shouldn't be so lazy that tools and configuration apps don't get developed for this DE and should be done from scratch.

Development of tools to ease the creation of themes, including cursors and icons.
Tools for designers to create themes and other eye candy aspects should be included in the DE. Something other *nix DEs seriously lack.

Include integration with WINE using links to library files that handle the functions required to run the desired programs
Make this DE cross-platform capable from the get go.

Must fully Comply with Fitts' Law
Well it is a law so yeah we should comply with it.

Must be portable to work with any windowing system such as Xorg, Wayland, Xfree2k and others.
No portability and we may as well commit this project to suicide before it ever gets started.

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-

 Re: Re: must?

 
 by Digit on: Oct 23 2011  
Score 50%
DigitDigit
Home

the must on compiz is a deal breaking fly in the ointment for me. pity, because the rest of it sounds great.

can it at least be turned off? opted out?

i mean,
is it a case of:
"must use 3d (and compiz is what's used for that)",
or
"IF 3d is used, it's compiz"
?

either way isnt particularly appealing to me (and a great many other people i know), but the latter is preferable of the two.

would there be no thought given to compatibility with other compositing options?

...or am i just being silly in how i'm interpreting this, and it's actually a case of "dont be silly, of course you can use other compositors if you want"?

(hopefully this is useful feedback, and not just an irritation)

stay free. go gpl. ;)
Reply to this

-

 Re: Re: Re: must?

 
 by Digit on: Oct 23 2011  
Score 50%
DigitDigit
Home

compositing/wm ... i should have said.

stay free. go gpl. ;)
Reply to this

-

 Re: Re: Re: Re: must?

 
 by novomente on: Oct 26 2011  
Score 50%
novomentenovomente
Home

Sounds good for me to save time by using what already has been programmed and what was the purpose to add this Must.


Reply to this

-

 Re: Re: Re: must?

 
 by technoshaun on: Oct 27 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

Okay if we don't use an already existing WM we would then have to write (most likely from scratch) another WM. Not only does that create a ton of work that does not need to be done it doesn't take advantage of what is readily available and already well implemented. Compiz can be 2D as well as 3D so why not use it. Why recreate the wheel when Compiz exists already. It sure makes a whole lot more sense to use than to not use it.

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-
.

 Re: Re: Re: Re: must?

 
 by novomente on: Oct 27 2011  
Score 50%
novomentenovomente
Home

Technoshaun. Maybe I didn't understand Digit clearly. So let me explain my stand. I agree to use something what already exist that we need not to write it from scratch. I mean that to use Compiz is not a MUST be used but rather CAN BE used.

There is still more time to decide what WM (2D or 3D) to use and I would like to start discussion on problems the WM must handle. If the Compiz is the best solution on what we want to create then I vote for Compiz. If another WM or technology is better I would better think of this technology.

It means that I am for looking best solution on goal we are reaching. And I'm afraid that we still don't know clearly our goal or goals in the meaning of for example which users we target our DE (professional, work, play, young people, old people), how to use DE - means quick usage or easy usage or nice design or can we make it to be used by universities in serious science etc. Which users do we want to switch to our DE (from Windows, MacOSX, Android, GNOME, KDE, XFCE, or get users of lightweight DEs such those using nonoverlapping windows and keyboard shortcuts).

It's a lot of things to think about our main goals. I am for long term living cycle of the DE. Thus I suggest to read this group - http://gnome-look.org/groups/?id=590 which you technoshaun already adviced.

There will be talking of new DE design and functionality. Maybe it could be good idea to cooperate. In that group people think about new DE in terms of usage, we in this group can talk about the MUSTs, solutions on how to create the DE and much more.

In the end I would like to kindly ask Digit to explain more about what he thinks and to talk more about his opinion and stands for. And if you are a programmer developer, please let us know you are, because we are moreover looking developers and coders. If you are not a coder just implement your ideas in our group - we welcome.


Reply to this

-

 Re: Re: Re: Re: Re: must?

 
 by technoshaun on: Oct 27 2011  
Score 50%
technoshauntechnoshaun
GnoMenu - Documentatio n Manager

There were 2 reasons I said Compiz.

1.) Oddly enough Compiz is the only WM that doesn't already have a DE made specifically made for it. Kwin, Gnome WM, and all any other WM I can mention has a DE for it. Compiz does not.

2.) Already well established and solid, uses the Gtk libraries and has structured support system in place.

Can we make our DE work with other WMs? Absolutely but we need to start somewhere first and Compiz is a very logical choice.

It isn't about it being free. Rather, its about the freedom it brings.
Reply to this

-

 Re: Re: Re: Re: Re: Re: must?

 
 by Digit on: Oct 28 2011  
Score 50%
DigitDigit
Home

"Oddly enough Compiz is the only WM that doesn't already have a DE made specifically made for it. Kwin, Gnome WM, and all any other WM I can mention has a DE for it. Compiz does not."

Not really sure if you just aren't familiar with many window managers, or if you mean something i'm not getting. i can name dozens of window managers that do not have a whole desktop environment to accompany them (i'll spare you that exercise though).

"Can we make our DE work with other WMs? Absolutely but we need to start somewhere first and Compiz is a very logical choice."

oh good that alleviates my concerns. i had thought that by your "MUST", you meant it would be a central component without which you wouldn't be able to use this DE.

GNU's modularity and freedom to choose components is one of it's strongest advantages, would have been a shame to brush it aside. glad to see this doesn't seem any more to be the case.

stay free. go gpl. ;)

-

 Re: Re: Re: Re: Re: Re: must?

 
 by Digit on: Oct 28 2011  
Score 50%
DigitDigit
Home

"Oddly enough Compiz is the only WM that doesn't already have a DE made specifically made for it. Kwin, Gnome WM, and all any other WM I can mention has a DE for it. Compiz does not."

Not really sure if you just aren't familiar with many window managers, or if you mean something i'm not getting. i can name dozens of window managers that do not have a whole desktop environment to accompany them (i'll spare you that exercise though).

"Can we make our DE work with other WMs? Absolutely but we need to start somewhere first and Compiz is a very logical choice."

oh good that alleviates my concerns. i had thought that by your "MUST", you meant it would be a central component without which you wouldn't be able to use this DE.

GNU's modularity and freedom to choose components is one of it's strongest advantages, would have been a shame to brush it aside. glad to see this doesn't seem any more to be the case.

stay free. go gpl. ;)

-

 Re: Re: Re: Re: Re: must?

 
 by MasKalamDug on: Oct 27 2011  
Score 50%
MasKalamDugMasKalamDug

I think a Desktop project should mean a DESKTOP project. It should apply where a real desk top once existed. That is, a clerical worker (in the broad sense of anyone engaged in clerical-like tasks - which means, to me, mostly reading and writing. Not necessarily text - numbers also. Approximately the content of Microsoft Office,

Or, stated another way, the Desktop should be optimized for experienced user of office-type applications.

If it is useful to other people - good. But the target population should be office workers. There are multiple millions of people in this category. Their work is crucial to society and it is not going to go away.


Reply to this

-

 Re: Re: Re: Re: Re: must?

 
 by Digit on: Oct 28 2011  
Score 50%
DigitDigit
Home

"In the end I would like to kindly ask Digit to explain more about what he thinks and to talk more about his opinion and stands for. And if you are a programmer developer, please let us know you are, because we are moreover looking developers and coders. If you are not a coder just implement your ideas in our group - we welcome."

i suppose i qualify as a developer, having worked on several distro projects, though my coding skills are still somewhat lacking. i spend a considerable amount of time surfing software to know what's out there, which lego bricks exist for us to play with, so to speak. among my many diverse interests, i also spend some of my time constructing my own "desktop environments" (of a sort) from various existing components, inspired in part at least, by the openbox version of crunchbang.
programming-wise, it's mostly just bash skills, and just barely touched on a handful of other programming/scripting languages. still would love to learn more about constructing guis and using toolkits (gtk foremost, but others too). so hard to find the time for it all though.

as for what i stand for, as i mention in my other response today, freedom. ;)
sensible defaults are of course of obvious importance, but if you cant change them to suit your own needs/preferences (because lets face it, everyone's needs and preferences are different) then it's a big fail imo.
similar story for how well integrated and cohesive a whole the DE is. i felt the old KDE (pre4) did this exceptionally well. i imagine it's a difficult thing to get right, creating a well integrated cohesive whole desktop experience that can handle a user changing the occasional component for alternatives, with minimal impact on that cohesive integrated experience.
i'm also strongly in favour of lightness, and responsiveness. like has been used as a mantra of sorts for google "every millisecond counts".

stay free. go gpl. ;)
Reply to this

-

 Re: Re: Re: Re: Re: must?

 
 by Digit on: Oct 28 2011  
Score 50%
DigitDigit
Home

"In the end I would like to kindly ask Digit to explain more about what he thinks and to talk more about his opinion and stands for. And if you are a programmer developer, please let us know you are, because we are moreover looking developers and coders. If you are not a coder just implement your ideas in our group - we welcome."

i suppose i qualify as a developer, having worked on several distro projects, though my coding skills are still somewhat lacking. i spend a considerable amount of time surfing software to know what's out there, which lego bricks exist for us to play with, so to speak. among my many diverse interests, i also spend some of my time constructing my own "desktop environments" (of a sort) from various existing components, inspired in part at least, by the openbox version of crunchbang.
programming-wise, it's mostly just bash skills, and just barely touched on a handful of other programming/scripting languages. still would love to learn more about constructing guis and using toolkits (gtk foremost, but others too). so hard to find the time for it all though.

as for what i stand for, as i mention in my other response today, freedom. ;)
sensible defaults are of course of obvious importance, but if you cant change them to suit your own needs/preferences (because lets face it, everyone's needs and preferences are different) then it's a big fail imo.
similar story for how well integrated and cohesive a whole the DE is. i felt the old KDE (pre4) did this exceptionally well. i imagine it's a difficult thing to get right, creating a well integrated cohesive whole desktop experience that can handle a user changing the occasional component for alternatives, with minimal impact on that cohesive integrated experience.
i'm also strongly in favour of lightness, and responsiveness. like has been used as a mantra of sorts for google "every millisecond counts".

stay free. go gpl. ;)
Reply to this

-
.

 Re: Re: Re: Re: Re: Re: must?

 
 by novomente on: Nov 5 2011  
Score 50%
novomentenovomente
Home

Would you like to join this group:

http://gnome-look.org/groups/?id=590

There is a lot of freedom to create new desktop environment design and new usage of computers. Developers are welcome to discuss everything, to bring ideas and possibly develop.

Same offer is for all readers here (technoshaun, Padster and others). I hope that the group will cooperate with our Free Desktop Environment group in some way.



-
.

 File Manager layout and menu

 
 by novomente on: Nov 5 2011  
Score 50%
novomentenovomente
Home

I made some File Manager layouts to make smaller window height. Get a closer look here:

http://novomente-activities.blogspot.com/2011/11/file-manager-window-layout.html

Also I thought the application menu could be visible only after right-clicking anywhere in an application window as shown here:

http://novomente-activities.blogspot.com/2011/11/application-menu-after-right-click.html

Of course everything is possible with application profiles. But something is a matter to discuss before creating the FreeDE (namely application icon and window titlebar).


Reply to this

-

 Re: File Manager layout and menu

 
 by MasKalamDug on: Nov 5 2011  
Score 50%
MasKalamDugMasKalamDug

Very nice looking work. But I, for one, would be rather indifferent as to what the default layout of parts is - provided it is easy to customize them and add add-ins.

And I have decided to deplore those secondary columns in menus (that are indicated by '>'; if they have a name I don't know what it is). In your example, of course, you must use at least one set of them because of the way the menu is displayed. Which makes me wonder whether the right click might rather bring up a different kind of sub-interface - for example a dialogue.


Reply to this

-
.

 Re: Re: File Manager layout and menu

 
 by novomente on: Nov 6 2011  
Score 50%
novomentenovomente
Home

Quote:
And I have decided to deplore those secondary columns in menus (that are indicated by '>'; if they have a name I don't know what it is). In your example, of course, you must use at least one set of them because of the way the menu is displayed. Which makes me wonder whether the right click might rather bring up a different kind of sub-interface - for example a dialogue.


This article I don't understand. What you mean by secondary columns? Do you mean the arrows ">"? Can you explain it little bit more?

In the picture there are 2 menus. The main menu is on the left and is similar to the GIMP menu when right-clicking the image (i.e. contains the application menubar in a vertical menu). The menu on the right is a sub-menu of the main menu.

In today applications (GIMP) when you right-click the main menu will pop up. Then choosing an item in the main menu brings a sub-menu of that item.

In the picture I draw a main menu. Each item of it has its own sub-menu which pops up after selecting an item of the main menu. First item of the main menu is a "Context" item. This item, when selected, brings up the context menu (usually popping up after right-clicking in todays applications). In the picture the main menu with preselected "Context" item and pre-opened "Context" sub-menu are shown right after right-clicking anywhere in the application. Only the "Context" sub-menu varies depending on the place where user right-clicks. So both menus are today usual menus (main menu and its sub-menus).

To your last sentence: I also think that after right-clicking in the application brings up some kind of a space where graphically should be the application functionality offer provided (i.e. for example toolbars, tabs, icons, text, radio buttons, videos, animations, and very different visualizations which I was talking in comment about UI-LEGO).


Reply to this

-

 Re: Re: Re: File Manager layout and menu

 
 by MasKalamDug on: Nov 6 2011  
Score 50%
MasKalamDugMasKalamDug

It appears that the name I didn't know should be sub-menu. Isn't obvious to me though I suppose it is to other people. The little symbol I called '>' is on the right end of every menu item that opens into a sub-menu. That's been standard since WIndows 3 at least.

There are two things at play here - function and appearance. I have no quarrel with right clicking to bring up the top of the menu so you can search down it for whatever you want. That's function and that's one reasonable way to do it. I have decided to not like sub-menus that are parallel to their parents - snuggling up to them so to speak - that's appearance.

The underlying problem is how to display a long list of diverse things - everything an application can do. Breaking the original list into a tree helps a lot because then you can drill down through shorter lists. The version of this problem in the file system is worse because usually there are many more files than there are actions in any application.

My guess is that there is no best way to do this. Hence it should be a customizable point. I have decided I think parallel sub-menus are ugly - so I should be allowed to easily modify the picture.

I don't think the solution to customization will be as easy as Lego Blocks. But that's a good ideal to aim at.


Reply to this

goto page: prev   1  2  3  4  5 

Add commentBackHomeCreate new groupView all groups



-
Linux42.org
-

Popular Groups
-

Newest Groups
-

FORUM
-

 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Artwork
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Content RSS   
Events RSS   

Participate
Groups
Forum
Add Content
Public API
About openDesktop.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2007-2016 openDesktop.org Team  
All rights reserved. openDesktop.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
openDesktop is a trademark of the openDesktop.org Team