Warning: session_start(): open(/tmp/sess_agpf66r9k4r4i4td4st6s1a2v0, O_RDWR) failed: No space left on device (28) in /www/H01/htdocs/lib/base/lib_base.php on line 280
Virus Recordings openDesktop.org
-
 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
CONTENT
-


-
- Content .- Fans  . 

Virus Recordings

  

KDE Wallpaper 1280x1024

Score 39%
bkeatingbkeating
Digital Simplicity Studios
Home
Virus Recordings
zoom

Link:  Link
Downloads:  2096
Submitted:  Dec 12 2001
Updated:  Dec 12 2001

Description:

This is my minimal take off of the Virus Recordings logo and text style. For those of you who don't know who the virus krew (Ed Rush & Optical, Rhymetyme)... better get a move on!

Cheers Linux Headz,
Lemme know what you think.
Ben.




Send to a friend
Subscribe
Other  Content  from bkeating
Report inappropriate content



goto page: prev   1  2  3  4 

-

 Webpage or Desktop?

 
 by opuntia on: Sep 18 2011  
Score 50%
opuntiaopuntia

After seeing the prototype, it kind of reminds me of some proto web page instead of a traditional desktop environment.


Reply to this

-

 Windows 8

 
 by MasKalamDug on: Sep 21 2011  
Score 50%
MasKalamDugMasKalamDug

Before we get involved in anything we need see what happens with Windows 8.

In case you have missed the fuss - Windows 8 comes with two GUI's. One is the old-fashioned kind (I have forgotten what they call it) and the other, called Metro, is like touch screen interfaces. The word Metro is convenient and I will keep using it until somebody objects.

I was preparing a discussion of touch screen implications when Microsoft announced. Now I propose to wait awhile and see what I can learn from Windows 8 users.

I have seen a real life Windows 8 Metro screen (in a store where I could not play with it) and, like a lot of people, I have reservations about it. But, at least, we might learn what not to do.


Reply to this

-

 Abstract Interfaces

 
 by MasKalamDug on: Sep 26 2011  
Score 50%
MasKalamDugMasKalamDug

Where I now stand is as follows:
(1) There is a physical display containing a rectangular array of physical pixels (colored dots)
(2) There is a parallel computer internal array of 32 bit software pixels that is connected to the physical array. I call this software array the display.
(3) There is a parallel array of message target addresses - one corresponding to each pixel.
(4) Input events happen at pixels and when they do event messages are sent to the corresponding message target
(5) There is an input event handler which associates each input event with some pixel (and therefore with the message target corresponding to the pixel).

And that, fundamentally is your GUI. The first thing to elaborate on is the invent handler.

Assume a mouse. The mouse is always associated with some pixel (or rather to the message target corresponding to some pixel). The mouse focus is usually that message target but can be grabbed. All the keyboard and mouse button events that are not grabbed by the event handler for some higher purpose go to the focus.

The mouse moves. I assume that generally the pixel it moves to has the same message target as the previous pixel. In the simpler situation no event message will be sent. The event handler will move the sprite image. If the pixels do not have the same message target the handler sends a mouse-leaving message to the old message target if it has been entered then it (re)starts a count down. If the count down ever goes to zero it sends a mouse-entering message to the new message target.

The actual pixel position is always globally accessible. It is possible for applications to
ask for mouse-tracking which means that an event is sent every time the mouse moves.

Applications can change the image the event handler uses for its sprite and tool-tips are realized as sprite image changes.

There must be at least one running object so that there is always some non-trivial target value in the message target array. This object would be the operating system or the shell.

Each application uses the same general model as the GUI recursively but there is only one global GUI that all applications share.

Summary: There are global resources - the pixel and target arrays and an event-handler process (which, of course, would need to be written).

Question: What else do I need to add?


Reply to this

-

 Target Audience

 
 by user333 on: Oct 5 2011  
Score 50%
user333user333

I guess this would be a very important thing to establish early on in designing.

I'm leaning more towards a power user or an office worker who needs to get things done fast without being frustrated by the interface.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-
.

 Re: Target Audience

 
 by user333 on: Oct 5 2011  
Score 50%
user333user333

I'm really sorry! Whenever I post a message to my group it keeps going to the latest artwork!!!

I wish someone would fix this problem

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Goals

 
 by user333 on: Oct 29 2011  
Score 50%
user333user333

It seems that we have never actually decided on our main goals, so now is a great time to decide ;) We need to come to an agreement before we go much farther, so please comment!

What is our overall goal? To become a popular DE, or be an example of an ideal interface? Or both?

I doubt that unless the project becomes as main-stream as Gnome or KDE, no application developer will change a program to be compatible with us. However, if we have ideal goals in place, but delay them so existing programs will still work, then later on perhaps we would have enough influence to cause application developers to use our methods. Or, possibly an existing DE would like our project and use some of it's ideas.

I (I'm speaking for myself here) think we should limit ourselves to only creating a "shell" but not our own development libraries, similar in some ways to Unity. While we could try to make an entirely different system from the start, people would not accept the changes, so we introduce them in stages. We can use some "hacks" such as a global menu that uses our design, but still use the standard GTK and QT. Then, if we get a good amount of acceptance, we can try introducing better ways of writing programs.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Front End - Back End

 
 by MasKalamDug on: Oct 31 2011  
Score 50%
MasKalamDugMasKalamDug

I formulated an application model where there was a front end, a back end and virtual shared storage.

I use gedit as a test bed but first lets start with the simplest possible text handling - a file browser. In a file browser the front end simply displays the contents of the file - nothing more.

I would say the virtual inner interface was, at a minimum, a struct like this:

Void* file_address
Int file_length
Char character
Bool step_right
Bool step_left
Int error

The two ends exchange messages saying "x = y" where x belongs to the interface and y is a new value to assign to x.

The front end starts by running some file-finder utility to find a file to display, then loading that file into data memory and finally sending two messages:

front: file_address = ...
front: file_length = ...

Then it starts to display the text. It gets the successive characters as follows:

front: step_right = 0
back: character = '...'

When the file is exhausted and there is still one more step_right

back: error = ...

After that every can be done by the front end. But that requires the front end to maintain a duplicate copy of the text. We can do a lot better by adding pair of data to the inner interface

Bool get_cursor
Cursor cursor

Cursor is an opaque type the front end does not understand. But the front end can save a cursor value and compare two cursor values. The get_cursor variable is really a command - as are step_right and step_left - that asks the back end to supply the value of cursor. Then the front end can, for example, remember where the cursor was when each page began and if it wants to, say, go back one page it sends:

front: cursor = ... // the value is saved cursor value

In order to get to an editor we need to bring in an edit add-in. I am cheating a little here because I am really assuming the browser is just the editor with edit turned off. A simple edit capacity can run with four more command in the interface:

Bool insert_left
Bool insert_right
Bool remove_left
Bool remove_right

The remove commands return the character removed and the insert command inserts the character.

The way add-ins work is that the messages are realized as function calls to one of two functions - front or back. The arguments are an identifier for what variable and the value to use. The back end starts by a select on the variable. If it can't find the variable it passes the problem to the first add-in.

Here I am designing the back end. This is certainly suggestive that the front end needs its own add-ins.

This is far from finished. Another installment another day.


Reply to this

goto page: prev   1  2  3  4 

Add commentBack




-
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