headers
Brandon Black | 1 Jun 03:14

Re: license question


Well, he chose what he chose, and at this stage if you don't like it 
you're probably best off just not helping a project you don't agree with 
the licensing terms of.  The standard response of those that favor 
gpl/lgpl over bsd licensing is of course, as you know, that they don't 
want to have their community efforts ripped off by heartless 
community-unfreindly companies who take advantage of BSD'd code.

Nell Weems wrote:

>Hello,
>
>i've noticed that the license for y-windows is LGPL. 
>is there any reason why this was picked over a
>BSD-style license? 
>i think it would be more desireable to develop 
>and more popular if it was in a 
>more liberal BSD license.
>
>not trying to start a flamewar, just wondering.
>
>regards, Nell
>
>
>
>	
>		
>__________________________________
>Do you Yahoo!?
>Friends.  Fun.  Try the all-new Yahoo! Messenger.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikko Rantalainen | 1 Jun 15:18
Picon
Picon

Re: Re: Design for Keyboard Shortcut Behaviour

Karl O'Keeffe <karl <at> monket.net> wrote:

> On May 26, 2004, at 4:00 am, Jonathan Harper wrote:
>>> As for Alt+Tab, what about making it open the traditional
>>> dialog box, but with the option of using arrow keys to jump
>>> around more quickly? Or something, because I'll be the first
>>> to admit that it's ugly, annoying, and frustrating. If I have
>>> twelve applications open, pressing Alt+Tab ten times to get 
>>> to the application I used ten times ago, I've wasted my time.
>>> Or Alt+Tab could highlight the tasks in the taskbar, and the
>>> arrow keys could allow one to navigate through them. Letting
>>> go would then bring that application to the forefront.
> 
> Yeah some alternative is needed as well I think. But I'd like to
> make sure that it provided a real difference in efficiency over
> alt-tab.
> 
> I'm not sure if using the arrow keys to navigate around is that
> much better than alt-tab, but I'm happy to have you convince me.

I think the alt-tab should work pretty much as it does today, though 
I would give it one big change: make it a list where each line is an 
application window with an icon to change to and each line has a 
number or a letter (1..9, 0, a..z, A...Z) so I can change directly 
to that window with one keypress. The old 
line-of-icons-in-the-center-with-current-title-below isn't good 
because I usually have too many windows with the same icon to make 
sense.

Note that alt-tabbing would still reorganize windows and "key
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elias Torres | 1 Jun 23:20
Picon
Picon

Re: Re: Design for Keyboard Shortcut Behaviour

El Tue, Jun 01, 2004 at 04:18:27PM +0300, Mikko Rantalainen escribió:
Hi,

> Karl O'Keeffe <karl <at> monket.net> wrote:
> 
> Note that alt-tabbing would still reorganize windows and "key 
> mapping" to each window would change so I couldn't trust that 
> alt-tab-8 is always the same window, instead it would be the 8th 
> window in the list that comes up when I press alt-tab. The behavior 
> would still be sensible, pressing alt-tab-2 would bring up window 
> that was active 2 windows ago. alt-tab-a would bring window that was 
> active 11 (10+first letter of alphabets) windows ago. Selecting that 
> window would bring that window to top of the list just like 
> alt-tab-tab-tab-tabbing would do.

Maybe the window could have a number the Tile in tilebar
+------------------------------------------------------------------------+
| (1)                 Google Search: y-windows - Mozilla Firefox | _ o x |
+------------------------------------------------------------------------+

In this case alt+tab+1 switches to that window. This is better because
you do not need to remember what window was open before.... well maybe
alt+tab+[leftarrow] or alt+tab+f2 could do that...

The taskbar (if any) may look like this
+------------------------------------------------------------------------+
|+-----------------------+-----------------------+----------------------+|
|| (1) Goole Search: ... | (4) X-Chat [2.0.8]... | (6) And so on...     ||
|+-----------------------+-----------------------+----------------------+|
+------------------------------------------------------------------------+
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Lorenzen | 3 Jun 00:11
Picon
Favicon

Re: Socket Error

On Mon, May 31, 2004 at 12:06:10AM -0500, Andrew Lovitt wrote:
> Hey Yole, I am a linux kinda-newbie, so sorry if this is something I should
> just know, but whenever I try to start up Y i get an error message:
> 
> "Failed to connect to Y Server via Unix domain socket: No such file or
> directory
> Aborted"
> 
> I tried to make edit the config file thinking that was the problem however
> the configuration file that comes with Y-2.1 is different than the one on
> the website, so that might be the problem.  The line relevent is:
> 
> driver/ipc/unix socket=/tmp/.Y-0

This looks right.

> do I have to do something to my network settings in linux?  Like allow
> socket connections etc?

No. 

> Did I not compile my server right?

Maybe ;-)

> Anyone else has this problem?  Thanks for your help.  I look forward to helping with this
> project (once I can get it running so I can test my coding :-) ).

I suppose You're trying to start Y via 'startY', right?
'startY' first starts up Y, takes it's PID and exports the YDISPLAY-Env.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Lovitt | 3 Jun 09:45
Picon
Favicon

RE: Socket Error

The only errors I seem to be getting when starting up Y is about 1 million
errors from gb.ykb things like:

parse errors
keyword errors

about ever line hits.  Will this prevent the server from actually starting
and thus prevent the socket from actually being connected?  How do I fix
this, is there a new keymap for 2.1 that doesn't come with the build?  Thanx
in advance.

bcseiny
Permalink | Reply | 0 comments |
headers
Nico Schottelius | 3 Jun 23:40

Low level graphics access

Hello!

Did anyone mention or think ggi for drawing things?
I currently re-read y-windows.org and wondered why you develop
on SDL and not on libggi.

Nico
Permalink | Reply | 3 comments |
headers
Andrew Suffield | 4 Jun 00:49
Picon
Favicon

Re: Low level graphics access

On Thu, Jun 03, 2004 at 11:40:19PM +0200, Nico Schottelius wrote:
> Did anyone mention or think ggi for drawing things?
> I currently re-read y-windows.org and wondered why you develop
> on SDL and not on libggi.

SDL was what was available on the lab boxes. And GGI would not be
noticably different, since it has no hardware acceleration unless you
install some horribly alpha kernel drivers. Which (a) you might as
well just use directly, and (b) are not really being developed much
these days.

--

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |
Permalink | Reply | 2 comments |
headers
Nico Schottelius | 4 Jun 08:52

Re: Low level graphics access

Andrew Suffield [Thu, Jun 03, 2004 at 11:49:34PM +0100]:
> On Thu, Jun 03, 2004 at 11:40:19PM +0200, Nico Schottelius wrote:
> > Did anyone mention or think ggi for drawing things?
> > I currently re-read y-windows.org and wondered why you develop
> > on SDL and not on libggi.
> 
> SDL was what was available on the lab boxes. And GGI would not be
> noticably different,

True, currently.

> since it has no hardware acceleration unless you
> install some horribly alpha kernel drivers.
> Which (a) you might as
> well just use directly,

I am wondering why one should rewrite hardware drivers again and again.
Why not contribute the work to one of the libggi targets?

> and (b) are not really being developed much these days.

Seems true, too. Although what they made is pretty impressive:

You have an GGI application and it searches for it's output device:

ggiterm works whether I got X running or I am using fb or I can even
use it with kgi.

I think that this setup could speed up building, as it 
concentrates on one thing and could make better parallel development:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Suffield | 4 Jun 12:10
Picon
Favicon

Re: Low level graphics access

On Fri, Jun 04, 2004 at 08:52:03AM +0200, Nico Schottelius wrote:
> > since it has no hardware acceleration unless you
> > install some horribly alpha kernel drivers.
> > Which (a) you might as
> > well just use directly,
> 
> I am wondering why one should rewrite hardware drivers again and again.
> Why not contribute the work to one of the libggi targets?

The hardware drivers are independent of GGI. It's just an abstraction
layer.

> > and (b) are not really being developed much these days.
> 
> Seems true, too. Although what they made is pretty impressive:
> 
> You have an GGI application and it searches for it's output device:
> 
> ggiterm works whether I got X running or I am using fb or I can even
> use it with kgi.

Same thing is true for SDL, which is just another abstraction
layer. Absent real hardware support, neither would be noticably better
than the other.

Also, GGI doesn't run on the 3d engine, and radeons can't do alpha
blending on the 2d engine. So it's the wrong abstraction layer
(again). Note that the right one does not exist.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Augie Fackler | 9 Jun 22:57
Picon
Favicon

Re: Design for Keyboard Shortcut Behaviour: Quasimode Command System

>> I'm not opposed to having a shortcut system at all, but I think that 
>> users shouldn't be encouraged to use one method over another. Many of 
>> the new users I help out eschew keyboard shortcuts entirely. Long 
>> term, very few non-technical users pick up the shortcuts, even if I 
>> encourage them to try it out. Many users seem to remember the 
>> sequence of events better if they use the mouse.
>
> The fact that very few non technical users pick up keyboard shortcuts 
> is the reason that I want to encourage their use. They are by in large 
> a lot more efficient that using the mouse. But because mouse commands 
> are currently much easier to discover users never bother trying 
> keyboard shortcuts.

How so? Using a menu item shows you the keyboard shortcut. Windows < XP 
shows the accelerator key all the time, and people didn't pick up on 
it, so now it is hidden to reduce clutter. That doesn't seem any less 
discoverable than a normal menu item. I think that people tend to learn 
one method and then lean on it until it becomes cumbersome. I tried for 
years to get people to use keyboard shortcuts over buttons and other 
systems, but the respose is always something like 'but what I do now 
works, even if it's slower.' Also, a system can be too discoverable. 
KDE has many easily discovered features, but ends up feeling very 
cluttered.

> You may have a point that sequences of events using the mouse are 
> easier to remember, I'll just hope that the difference isn't too 
> severe.
> <snip>
> The advantage of not requiring the letter to be in the label is nice, 
> but I think it is outweighed by the disadvantage of the shortcut being
(Continue reading)

Permalink | Reply | 1 comment |

Gmane