profile-image

novomente

novo mente

OneColor

Metacity Themes Aug 10 2017
Score 68%
68.00 Likes
32 Dislikes

:-) Apollo 11 (joke)

Wallpaper Other Jul 30 2017
Score 60%
60.00 Likes
40 Dislikes

OneColor XFCE

XFCE/XFWM4 Themes Jul 18 2017
Score 75%
75.00 Likes
25 Dislikes

City

Metacity Themes Mar 22 2017
Score 60%
60.00 Likes
40 Dislikes

Colored Snow

Wallpaper Other Feb 17 2017
Score 50%
50.00 Likes
50 Dislikes

Glazy XFCE

FVWM Themes Feb 17 2017
Score 54%
54.00 Likes
46 Dislikes

Simply Retro XFCE

XFCE/XFWM4 Themes Feb 02 2017
Score 53%
53.00 Likes
47 Dislikes

Glazy

Metacity Themes Jan 16 2017
Score 63%
63.00 Likes
37 Dislikes

Plasmatic

GDM Themes Jan 03 2017
Score 67%
67.00 Likes
33 Dislikes

nu XFCE

XFCE/XFWM4 Themes Dec 29 2016
Score 44%
44.00 Likes
56 Dislikes

Gillet

Metacity Themes Dec 28 2016
Score 63%
63.00 Likes
37 Dislikes

Striped Glassy

Metacity Themes Dec 26 2016
Score 61%
61.00 Likes
39 Dislikes

City XFCE

XFCE/XFWM4 Themes Dec 26 2016
Score 63%
63.00 Likes
37 Dislikes

Polaris

Metacity Themes Dec 26 2016
Score 73%
73.00 Likes
27 Dislikes

Electronica

Metacity Themes Dec 26 2016
Score 71%
71.00 Likes
29 Dislikes

Fugitive

Metacity Themes Dec 26 2016
Score 68%
68.00 Likes
32 Dislikes

Fugitive XFCE

XFCE/XFWM4 Themes Dec 26 2016
Score 58%
58.00 Likes
42 Dislikes

Saint Linux

Wallpapers Tux/Linux Dec 26 2016
Score 60%
60.00 Likes
40 Dislikes
City Metacity Themes
Mar 24 2017
Plasmatic GDM Themes
Jan 03 2017
OneColor Metacity Themes
Jul 20 2016
Virus Recordings Wallpaper Other
Nice prototype. The interactivity makes the ideas included more clear. As playground it is perfect.

With HTML5, CSS3 and JavaScript there is a lot of things possible. The UI may look any way. It reminds me a time where applications had their own original look and usability. But at those times it was a problem, because users must learn every application to use.

The problem was solved over years with GUI toolkit (GUI components etc.). Such toolkit was library programmed for each operating system or each Desktop Environment.

It was also a solution to low memory of a desktop computer, where application shared the GUI toolkit in order to save memory footprint.

With HTML5 etc., there is similar problem to per application original look and usage. One can say it can be solved the similar way with programming a HTML, Javascript toolkit. Yes it is possible. But in the end many applications could be unsatisfied with such toolkit and their developers would choose to create their own toolkit. So I think that instead of making a toolkit or HTML/JavaScript API, there must be some guideline (concept) desription which most of application GUIs or most of GUI libraries or most HTML/JavaScript toolkits have to follow.

The guidelines only says how the desktop would look and function. Such thing is already done with Human Interface Guidelines ( http://en.wikipedia.org/wiki/Human_interface_guidelines ) which should the DE guideline stand on and freedesktop.org ( http://en.wikipedia.org/wiki/Freedesktop.org ) which is a project to make X-Window toolkits offer the same usage from a user's experience (such that applications using KDE toolkit would be very similar in usage as applications in GNOME and vice versa). The HTML/JavaScript guideline should play the same role as freedesktop.org.

The guideline must be not too complex in order to allow a wide range of applications to follow it. On the other hand there could be some more guidelines (concepts) for example a General User UI Concept, Administration Concept (concept for system administrators - terminal etc.), Graphics and multimedia concepts (like DTP, 3D creations, movie creations etc.), Server System Concept, and so on.

Maybe we should make difference between a "guideline" term and a "concept" term. The difference is that "guideline(s) is enough general to make wide variety of GUIs following it. The "concept" is more specific and describes for example a HTML/JavaScript "components", desktop, icons, functionality. The concept is only a document describing functionality and look of a toolkit, but it is not programmed toolkit. To explain it exactly lets say the GNOME is a coded toolkit. The GNOME concept is only a document describing the GNOME toolkit. With such description the GNOME developers exactly know what is a Gnome-Shell and what should it do and then they develop the Shell in C++.

So we can make a guideline and then a FluiDE-HTML/JavaScript concept (what is a document describing the FluiDE desktop) and developers can then code their own FluiDE toolkit exactly build for their single application. Then they need not to share any of HTML/JavaScript code among applications from different developer groups and all applications will look and function very similar.

Of course as well as web application frameworks are created (Joomla, Drupal etc.: http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks ) there could also be finished coded FluiDE toolkit or many other toolkits and frameworks shared among applications from wide range of developers.

The primary goal of a guideline is making usage over wide range of applications very similar (preventing a user to learn how to use every application) etc. The concept is a specific (but still anough general and open) to create UI (to say it exactly the GNOME concept exactly describes the GNOME DE and developers can create their own toolkits and frameworks which would look and behave exactly as a GNOME DE - so there could be per application specific GNOME DEs with or without sharing the framework).

Our task could be only to create very smart concept(s) which they really worth to follow. Plus code a FluiDE DE - as a real working example of what the concept is capable of. And if the FluiDE code will be perfectly written, it could be shared and meet with a success.

These are my thoughts today.
Sep 20 2012
Virus Recordings Wallpaper Other
Nice prototype. The interactivity makes the ideas included more clear. As playground it is perfect.

With HTML5, CSS3 and JavaScript there is a lot of things possible. The UI may look any way. It reminds me a time where applications had their own original look and usability. But at those times it was a problem, because users must learn every application to use.

The problem was solved over years with GUI toolkit (GUI components etc.). Such toolkit was library programmed for each operating system or each Desktop Environment.

It was also a solution to low memory of a desktop computer, where application shared the GUI toolkit in order to save memory footprint.

With HTML5 etc., there is similar problem to per application original look and usage. One can say it can be solved the similar way with programming a HTML, Javascript toolkit. Yes it is possible. But in the end many applications could be unsatisfied with such toolkit and their developers would choose to create their own toolkit. So I think that instead of making a toolkit or HTML/JavaScript API, there must be some guideline (concept) desription which most of application GUIs or most of GUI libraries or most HTML/JavaScript toolkits have to follow.

The guidelines only says how the desktop would look and function. Such thing is already done with Human Interface Guidelines ( http://en.wikipedia.org/wiki/Human_interface_guidelines ) which should the DE guideline stand on and freedesktop.org ( http://en.wikipedia.org/wiki/Freedesktop.org ) which is a project to make X-Window toolkits offer the same usage from a user's experience (such that applications using KDE toolkit would be very similar in usage as applications in GNOME and vice versa). The HTML/JavaScript guideline should play the same role as freedesktop.org.

The guideline must be not too complex in order to allow a wide range of applications to follow it. On the other hand there could be some more guidelines (concepts) for example a General User UI Concept, Administration Concept (concept for system administrators - terminal etc.), Graphics and multimedia concepts (like DTP, 3D creations, movie creations etc.), Server System Concept, and so on.

Maybe we should make difference between a "guideline" term and a "concept" term. The difference is that "guideline(s) is enough general to make wide variety of GUIs following it. The "concept" is more specific and describes for example a HTML/JavaScript "components", desktop, icons, functionality. The concept is only a document describing functionality and look of a toolkit, but it is not programmed toolkit. To explain it exactly lets say the GNOME is a coded toolkit. The GNOME concept is only a document describing the GNOME toolkit. With such description the GNOME developers exactly know what is a Gnome-Shell and what should it do and then they develop the Shell in C++.

So we can make a guideline and then a FluiDE-HTML/JavaScript concept (what is a document describing the FluiDE desktop) and developers can then code their own FluiDE toolkit exactly build for their single application. Then they need not to share any of HTML/JavaScript code among applications from different developer groups and all applications will look and function very similar.

Of course as well as web application frameworks are created (Joomla, Drupal etc.: http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks ) there could also be finished coded FluiDE toolkit or many other toolkits and frameworks shared among applications from wide range of developers.

The primary goal of a guideline is making usage over wide range of applications very similar (preventing a user to learn how to use every application) etc. The concept is a specific (but still anough general and open) to create UI (to say it exactly the GNOME concept exactly describes the GNOME DE and developers can create their own toolkits and frameworks which would look and behave exactly as a GNOME DE - so there could be per application specific GNOME DEs with or without sharing the framework).

Our task could be only to create very smart concept(s) which they really worth to follow. Plus code a FluiDE DE - as a real working example of what the concept is capable of. And if the FluiDE code will be perfectly written, it could be shared and meet with a success.

These are my thoughts today.
Sep 20 2012
Virus Recordings Wallpaper Other
Sep 18 2012
Virus Recordings Wallpaper Other
Hi and Welcome to the group. It is very nice to see some more person here :)

I have just read your comment. My English is still not perfect, so I had to read it three times and slowly with dictionary and I hope I understand it correctly. As I understand you are talking about booting Operating System. Fast load with text bases windowing system, where you can work in the meantime the GUI is loaded. With the option the GUI need not to be loaded. It sounds like interesting option.

I assume you have also some administrator skills (or Are you an experienced administrator professional?). Ok. In some discussion in my country (not English) I posted my dream when Operating System fully boots in 1 to 3 seconds. I got answers that the long booting is due to BIOS (which makes many checks) and then Linux optimizations (checks, loaded services and loading many mess of unoptimized system). I also got some answers on Operating Systems to load very fast.

For example linux distribution "Tiny Core" boots in VirtualBox at about 7 seconds (counted after pressing Run button). I also got this youtube video, where some guy boots Windows XP in VirtualBox. It is very interesting. I just note that someone commented the video as "When I watched the video, I almost fell off the chair, how fast it worked." - what speaks for itself - link on video follows:

http://youtu.be/H-LinhTC4jw

Some new talks about Microsoft being working on new operating system. It should remove Windows and it should be much smaller in size than Windows. I suppose the system is about virtualisation. But of course Microsoft specific implementation of monopol.

What do you think about fast full system booting? Is is worth to work on it? Or is it better to devote time to get lower UI loaded much faster with possibility to load GUI later?
May 31 2012
Virus Recordings Wallpaper Other
Apr 23 2012
Virus Recordings Wallpaper Other
Apr 18 2012
Virus Recordings Wallpaper Other
I think, David, that you are absolutely right with all you have said.

Firstly the interactive fiction - those text based games were very amusing and had many possibilities. More possibilities than their graphical today versions (Adventures point & click). I was thinking about the text base GUI the same way as you. I wanted to create a text base "kernel" while the GUI could implement it in various ways (with mouse or with keyboard; or with other devices).

The speech I named in TVc is only a future. I meant to develop text based UI with keyboard as a communication device and speech (sometime in the future) would only read the text from memory (synthesize) or use special program for speech recognition (to hear voice) which is converted in a text (and maybe some signs for stress, voice colour and vice versa) with which the OS then works.

Thus the goal I can think recently is only a text based system (without a speech). Interactive fiction is the part I would like to follow.

Secondly the two-dimensional array of pixels. I was talking (in our group) about a "scrollpad". I explained that it is not the point to point device for pixels. More it is a device to move from object to object on the screen (from button to button, from button to text filed, from text field to radio buttons - just to follow X and Y axis and the nearest object).

And that is exactly your proposed frame buffer. I think the mouse could be used the same way as "scrollpad". And both hardware devices - touchpad and mouse - have the ability to become a pixel to pixel pointing device for graphical reasons like image manipulation, 3D graphics etc. Both devices has the capability of using gestures. The touchpad hardware has the advantage that it could be a small or big touchscreen where various things can be displayed and by touching them with finger or with stylus can make appropriate action. The stylus also can be used as a pixel to pixel pointing device, great in handwriting, drawing and also 3D designing.

I think that the frame buffer is the good basis. But to be honest I didn't think of 3D GUI yet, what could be great in some future Human <-> Computer interaction. There are already some devices allowing interaction in a 3D world. The real best known is the XBOX Kinect. Such device (already sold to end users) proposed an era of 3D like devices and many more.

So I would like to think of such matter in our project - looking to a log term living age of it.
Apr 15 2012
Virus Recordings Wallpaper Other
Apr 14 2012
Virus Recordings Wallpaper Other
Apr 13 2012
Virus Recordings Wallpaper Other
Apr 12 2012
Virus Recordings Wallpaper Other
Few days ago I played with TinyCore - it is a Linux distribution of small size (13mb - yes "13 mega bytes"). It surprised me because into that 13mb it was possible to add graphical user interface and full linux. I was also delighted by its boot/shutdown timings. It is really fast. Many times i was thinking of an OS to boot very quickly. I hoped that future hardware would allow it (boot time = 1 - 3 seconds). But instead new versions of OSs implemented more features and the boot time took longer. This is one point.

Now I was thinking of our FluiDE DE to be as a mockup with windowing UI on text base screen. I intended that just for training and making the development easy while making mockup. I returned to MS-DOS applications and tried to think of some useful text base DE. These are very interesting thoughts. And suddenly my brain surprised me with some idea.

How about to create a DE on text based screen with full GNOME, KDE libraries support. It means to run GNOME/KDE etc applications on that text base screen DE without rewriting them. I think this is possible. But then my thoughts went more forward and I imagined that an application should be fully independent of the DE. I imagined that an application is written once and then only it's UI separated part would vary - ether for KDE or GNOME or text base DE or whatever. And now I'm starting to think of a technology, which makes the development of UI design/functionality possible. That's what we try to work on.

The goal of creating an application is to have that application available for all DEs (GNOME/KDE/XFCE/etc.) without rewriting the main part of it.

The second goal of better Operating System is to have such OS that is very very fast with small memory trace (probably without many features like nice look of the OS), allowing to give the hardware potential possibilities to applications and documents. It means that for example while the OS has not anti alias fonts, it allows the Office application to use them. This is the example of feature less OS and feature rich application model. Well I'm sure some project exists to handle this goal (maybe the "QNX" and others). I just imagine it to be very small and very fast like the TinyCore (but not as small as 13mb). That's why I also imagined the text base screen DE and full potential of it (for some type of usage).
Apr 11 2012
Virus Recordings Wallpaper Other
Apr 10 2012