Re: [dwm] java 7 and dwm
2008/1/23, Renick Bell <[EMAIL PROTECTED]>: > Yeah, obviously I don't really want to be using java. However, I use > SuperCollider (http://supercollider.sourceforge.net/ ) to do realtime > audio stuff. On Linux, SwingOSC is the only way to use GUI code > written by people on Macs or Windows. To be able to play with other > people's work, and for them to be able to use mine, I'm stuck with > SwingOSC for the moment. I'd like to have an alternative (and may > eventually write it myself), but in the meantime I still want to be > able to play with that GUI code while using dwm. > > Icedtea seems like the most ethical choice, and it was already > packaged as well. Too bad it doesn't seem to solve the issue. So, > again, any suggestions? > > Renick > Maybe not a good solution and an off topic here, but if you want to work with high quality sound you could have a look at jammin, ardour and the other jack based stuff. It works great for me, it has no java dependencies and no problems with dwm. Though I don't know SuperCollider at all and I could be completely wrong. hth, -- - yiyus || JGL .
Re: [dwm] java 7 and dwm
2008/1/23, Renick Bell <[EMAIL PROTECTED]>: > Anselm> Is IcedTea based on the Sun source code? > > http://iced-tea.org/wiki/FrequentlyAskedQuestions > > " What is IcedTea? > > "Not all of the source code that makes up the JDK is available under > an open-source license. In order to build an OpenJDK binary from > source code, you must first download and install one or more of the > following files from which the build process will copy over 'binary > plugs' for these encumbered components." (from > http://openjdk.java.net/) > > IcedTea is a build harness for the OpenJDK that provides stubs and GNU > Classpath replacements for the encumbered binary plugs, and allows the > OpenJDK to be bootstrapped against GCJ. It is not a fork of the > OpenJDK, and doesn't contain the OpenJDK source code." Should be the default build harness for Sun OpenJDK if they want to be a bit more open source serious. > > Someone brought up this post below with regards to this issue. I lack > enough skill currently to implement such a solution. Has anyone made a > patch for dwm along these lines? Maybe I've overlooked it: > > http://article.gmane.org/gmane.comp.lang.haskell.xmonad/1790 Ok, java and its siblings are messes to maintain. Nothing new. > > Sylvain> Get the java code, try to compile it with 100% open source tools... > > Yeah, obviously I don't really want to be using java. However, I use > SuperCollider (http://supercollider.sourceforge.net/ ) to do realtime > audio stuff. On Linux, SwingOSC is the only way to use GUI code > written by people on Macs or Windows. To be able to play with other > people's work, and for them to be able to use mine, I'm stuck with > SwingOSC for the moment. I'd like to have an alternative (and may > eventually write it myself), but in the meantime I still want to be > able to play with that GUI code while using dwm. http://trolltech.com/products/qt http://www.gtk.org/ http://www.pygtk.org/ http://ruby-gnome.sourceforge.net/ http://ubuntustudio.org/ http://www.linuxaudio.org/ > > Icedtea seems like the most ethical choice, and it was already > packaged as well. Too bad it doesn't seem to solve the issue. So, > again, any suggestions? Patch java and/or Code in C. > > Renick > > -- > Renick Bell > http://the3rd2nd.com I don't think java and its siblings will have room on suckless.org because: "Dedicated to software which sucks less. Home of wmii, dwm, libixp, and other quality software with a focus on simplicity, clarity, and frugality."
Re: [dwm] java 7 and dwm
On 1/23/08, Renick Bell <[EMAIL PROTECTED]> wrote: > audio stuff. On Linux, SwingOSC is the only way to use GUI code > written by people on Macs or Windows. To be able to play with other > people's work, and for them to be able to use mine, I'm stuck with bullshit tk, gtk, gtk2, qt, fltk, wx, ... these are all known to work cross platform (of course none of them is usable, including swingosc)
Re: [dwm] java 7 and dwm
*sigh* It would be nice if people actually read emails before replying. Renick is correct, swingOSC is a cross-platform gui solution *for* supercollider (meaning that its a gui toolkit that is intergrated with the language). At the moment it is the *only* one, it has nothing to do with the myriad of other gui toolkits and their particular cross-platform availability. Yes, he could well take gtk, qt, wx, whatever and build another setup but that wasnt the question. Perhaps he wasn't clear enough, but there's definetly no "bullshit" involved. James On Jan 23, 2008 7:23 PM, Szabolcs Nagy <[EMAIL PROTECTED]> wrote: > On 1/23/08, Renick Bell <[EMAIL PROTECTED]> wrote: > > audio stuff. On Linux, SwingOSC is the only way to use GUI code > > written by people on Macs or Windows. To be able to play with other > > people's work, and for them to be able to use mine, I'm stuck with > > bullshit > > tk, gtk, gtk2, qt, fltk, wx, ... > > these are all known to work cross platform > (of course none of them is usable, including swingosc) > >
Re: [dwm] java 7 and dwm
On 1/23/08, James Baker <[EMAIL PROTECTED]> wrote:
> Renick is correct, swingOSC is a cross-platform gui solution *for*
> supercollider (meaning that its a gui toolkit that is intergrated with
> the language).
his statement ("..SwingOSC is the only way to use GUI code.. ") is still false
he can use any cross platform gui since the supercollider api is open
Re: [dwm] java 7 and dwm
On Jan 23, 2008 9:22 PM, Szabolcs Nagy <[EMAIL PROTECTED]> wrote:
> On 1/23/08, James Baker <[EMAIL PROTECTED]> wrote:
> > Renick is correct, swingOSC is a cross-platform gui solution *for*
> > supercollider (meaning that its a gui toolkit that is intergrated with
> > the language).
>
> his statement ("..SwingOSC is the only way to use GUI code.. ") is still false
>
> he can use any cross platform gui since the supercollider api is open
>
>
ok sure lets play quotes...
"I'm stuck with SwingOSC for the moment. I'd like to have an
alternative (and may
eventually write it myself), but in the meantime I still want to be
able to play with that GUI code while using dwm."
whatever, like it or not atm SwingOSC is the only developed
cross-platform gui system for sc3 and developing a native
cross-platform replacement is hardly a quick hack. So in the meantime
as renick stated it would be good to be able to use what is already
available.
[dwm] dietline - minimalistic readline implementation
As I request in a previous mail I have developed a readline-like library in a minimalistic way avoiding the unnecessary overhead and dependency with a single portable c file. I have tested this on NetBSD, GNU/linux and native w32 and works pretty fine. The library currently supports autocompletion of a single word using argc, argv (this is just a PoC). Allows to change the prompt, and change some configuration stuff for it. No vi or emacs mode yet (should i read inputrc?). Current support: - history log - navigate history with ^n/^p or up/down keys - autocompletion for one keyword (no nested yet) - tab key hooked for autocompletion - support to change the prompt - handle ^C and ^D You can download the implementation here: http://news.nopcode.org/dietline.c To test it on w32 just put __UNIX__ to 0 and __WINDOWS__ to 1 :) $ gcc dietline.c $ ./a.out foo bar foobar foocowblob foocowguai = foo foo foobar foocowblob foocowguai = foocow foocowblob foocowguai = foocowb = foocowblob I plan to use this library instead of readline for radare (radare.nopcode.org) so I plan to continue working on it. Patches and ideas are welcome. --pancake
Re: [dwm] dietline - minimalistic readline implementation
Oops I forgot to say that it supports a dmenu-mode (this code inherits from
the old eread program I send to the list few months ago).
Usage is quite simple:
int main(int argc, char **argv)
{
char *ret;
dl_init();
dl_prompt = "$ ";
do {
ret = dl_readline(argc, argv);
if (ret) {
printf(" [line] '%s'\n", ret);
dl_hist_add(ret);
}
} while(ret!=NULL);
dl_free();
}
Have fun!
--pancake
On Wed, Jan 23, 2008 at 04:31:57PM +0100, pancake wrote:
> As I request in a previous mail I have developed a readline-like
> library in a minimalistic way avoiding the unnecessary overhead
> and dependency with a single portable c file.
>
> I have tested this on NetBSD, GNU/linux and native w32 and works
> pretty fine.
>
> The library currently supports autocompletion of a single word
> using argc, argv (this is just a PoC). Allows to change the prompt,
> and change some configuration stuff for it.
>
> No vi or emacs mode yet (should i read inputrc?).
>
> Current support:
>
> - history log
> - navigate history with ^n/^p or up/down keys
> - autocompletion for one keyword (no nested yet)
> - tab key hooked for autocompletion
> - support to change the prompt
> - handle ^C and ^D
>
> You can download the implementation here:
>
> http://news.nopcode.org/dietline.c
>
> To test it on w32 just put __UNIX__ to 0 and __WINDOWS__ to 1 :)
>
> $ gcc dietline.c
> $ ./a.out foo bar foobar foocowblob foocowguai
> = foo
> foo foobar foocowblob foocowguai
> = foocow
> foocowblob foocowguai
> = foocowb
> = foocowblob
>
> I plan to use this library instead of readline for radare (radare.nopcode.org)
> so I plan to continue working on it.
>
> Patches and ideas are welcome.
>
> --pancake
>
Re: [dwm] dietline - minimalistic readline implementation
Very nice idea. What about collecting all these "baseutilities" and
put them on suckless.org? If we can write more utilities we may get a
complete suckless userspace... :)
2008/1/23, pancake <[EMAIL PROTECTED]>:
> Oops I forgot to say that it supports a dmenu-mode (this code inherits from
> the old eread program I send to the list few months ago).
>
> Usage is quite simple:
>
> int main(int argc, char **argv)
> {
> char *ret;
>
> dl_init();
> dl_prompt = "$ ";
>
> do {
> ret = dl_readline(argc, argv);
> if (ret) {
> printf(" [line] '%s'\n", ret);
> dl_hist_add(ret);
> }
> } while(ret!=NULL);
>
> dl_free();
> }
>
> Have fun!
>
>
> --pancake
>
> On Wed, Jan 23, 2008 at 04:31:57PM +0100, pancake wrote:
> > As I request in a previous mail I have developed a readline-like
> > library in a minimalistic way avoiding the unnecessary overhead
> > and dependency with a single portable c file.
> >
> > I have tested this on NetBSD, GNU/linux and native w32 and works
> > pretty fine.
> >
> > The library currently supports autocompletion of a single word
> > using argc, argv (this is just a PoC). Allows to change the prompt,
> > and change some configuration stuff for it.
> >
> > No vi or emacs mode yet (should i read inputrc?).
> >
> > Current support:
> >
> > - history log
> > - navigate history with ^n/^p or up/down keys
> > - autocompletion for one keyword (no nested yet)
> > - tab key hooked for autocompletion
> > - support to change the prompt
> > - handle ^C and ^D
> >
> > You can download the implementation here:
> >
> > http://news.nopcode.org/dietline.c
> >
> > To test it on w32 just put __UNIX__ to 0 and __WINDOWS__ to 1 :)
> >
> > $ gcc dietline.c
> > $ ./a.out foo bar foobar foocowblob foocowguai
> > = foo
> > foo foobar foocowblob foocowguai
> > = foocow
> > foocowblob foocowguai
> > = foocowb
> > = foocowblob
> >
> > I plan to use this library instead of readline for radare
> > (radare.nopcode.org)
> > so I plan to continue working on it.
> >
> > Patches and ideas are welcome.
> >
> > --pancake
> >
>
>
--
http://www.gnuffy.org - Real Community Distro
http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy)
[dwm] a patch to solve the java issue (gray windows) with dwm?
Stated as explicitly as possible: 1. I need to be able to use java gui apps and dwm at the same time. My justification is in the extended footnote. 2. This post seems to explain why java apps only appear as gray windows in dwm, and it provides a patch for the Xmonad window manager: http://article.gmane.org/gmane.comp.lang.haskell.xmonad/1790 3. I have been unable to locate a similar patch for dwm. 4. Has such a patch been written by anyone? 5. I currently am unable to write such a patch. 6. I certainly wouldn't expect such a hack to become part of the official dwm source. 7. Hacking the java source would be a waste of time. 8. Java's own 1.7.0 appears to be pre-beta. http://java.sun.com/downloads/ea/ I don't want to be an early adopter/tester of Sun's software. I want to use my package manager's icedtea package for license reasons; however, for practical reasons I would use any of my package manager's java packages. Those don't include another 1.7.0 java. 9. The dwm source, because of its conciseness, seems to be an appropriate place to apply a patch. 9. Is there an alternative solution to the problem such that I could use dwm, have properly functioning java apps, and avoid hassle with java source or pre-beta Sun products? Thanks for assistance. The justification for using java is below. Renick --- ...my justification for use of java and dwm simultaneously. If you would like to reply to this section, please start a new off-topic thread. I don't mind discussing it, but please don't foul the on-topic thread about java and dwm. Again, stated as explicitly as possible: 1. I use SuperCollider for realtime audio work. SuperCollider is a programming language. http://supercollider.sourceforge.net/ 2. People develop GUI applications using SuperCollider. On Macs, users have access to the native GUI toolkit from within SuperCollider. 3. Those using Windows and Linux don't have access to native GUI toolkits from within SuperCollider at the moment. There is no gtk, qt, or other toolkit binding/library for Linux users which is also cross-platform. 4. Linux and Windows users can use SwingOSC, which is a cross-platform GUI toolkit based on Swing. http://www.sciss.de/swingOSC/ 5. Using SwingOSC allows me to use programs written by Mac and Windows users. It also allows those users to use my code. 6. Making another toolkit available within SuperCollider, such as gtk, is significant work which will require weeks, if not months. 7. I don't like using java for license reasons, performance reasons, and aesthetic reasons. 8. I would like to eventually develop a concise, efficient, and lightweight alternative. 9. In the meantime, I want to use GUI code written by other SuperCollider users. 10. I also want to use code which I wrote while using wmii, under which java apps functioned properly. 11. That means I must use SwingOSC until I have developed an alternative. 12. That means I must have java. 13. I think dwm is the best window manager for me. 14. Therefore, I want to use java and dwm together until I can be free from java. -- Renick Bell http://the3rd2nd.com
Re: [dwm] a patch to solve the java issue (gray windows) with dwm?
> just to make sure: you did read the dwm man page (BUGS section), and > setting AWT_TOOLKIT=MToolkit in your environment does not help, does > it? Yes, I tried this solution. It did not work. Thanks for the suggestion! Renick -- Renick Bell http://the3rd2nd.com
Re: [dwm] a patch to solve the java issue (gray windows) with dwm?
This patch is not a solution. is just a hack. If you read the patch, and the archives in tihs mailing list you'll find the reason and some snippets of java code (and the path to the buggy code into the java source). The patch obviously is not affordable for dwm because monad is written in Haskell...but a patch for dwm would be probably a single line in C. So the solution is not to hack into the window manager because its a bug in the virtual machine..well..in reality its not a bug, its an ugly hack :P And fix hacks with hacks is ugly. :P FYI: What Java does is to check for the window manager name and if it's known perform correctly and if not show a grey screen. The solution is just to remove these lines or add "dwm" as a valid window manager. Any X11 guru to provide a hack for those unhappy users? I have no time to look at it now, and my Java works fine. --pancake On Thu, Jan 24, 2008 at 12:51:08AM +0900, Renick Bell wrote: > Stated as explicitly as possible: > > 1. I need to be able to use java gui apps and dwm at the same time. My > justification is in the extended footnote. > > 2. This post seems to explain why java apps only appear as gray > windows in dwm, and it provides a patch for the Xmonad window manager: > http://article.gmane.org/gmane.comp.lang.haskell.xmonad/1790 > > 3. I have been unable to locate a similar patch for dwm. > > 4. Has such a patch been written by anyone? > > 5. I currently am unable to write such a patch. > > 6. I certainly wouldn't expect such a hack to become part of the > official dwm source. > > 7. Hacking the java source would be a waste of time. > > 8. Java's own 1.7.0 appears to be pre-beta. > http://java.sun.com/downloads/ea/ > I don't want to be an early adopter/tester of Sun's software. I want > to use my package manager's icedtea package for license reasons; > however, for practical reasons I would use any of my package manager's > java packages. Those don't include another 1.7.0 java. > > 9. The dwm source, because of its conciseness, seems to be an > appropriate place to apply a patch. > > 9. Is there an alternative solution to the problem such that I could > use dwm, have properly functioning java apps, and avoid hassle with > java source or pre-beta Sun products? > > Thanks for assistance. The justification for using java is below. > > Renick > > --- > > ...my justification for use of java and dwm simultaneously. If you > would like to reply to this section, please start a new off-topic > thread. I don't mind discussing it, but please don't foul the on-topic > thread about java and dwm. > > Again, stated as explicitly as possible: > > 1. I use SuperCollider for realtime audio work. SuperCollider is a > programming language. > http://supercollider.sourceforge.net/ > > 2. People develop GUI applications using SuperCollider. On Macs, users > have access to the native GUI toolkit from within SuperCollider. > > 3. Those using Windows and Linux don't have access to native GUI > toolkits from within SuperCollider at the moment. There is no gtk, qt, > or other toolkit binding/library for Linux users which is also > cross-platform. > > 4. Linux and Windows users can use SwingOSC, which is a cross-platform > GUI toolkit based on Swing. > http://www.sciss.de/swingOSC/ > > 5. Using SwingOSC allows me to use programs written by Mac and Windows > users. It also allows those users to use my code. > > 6. Making another toolkit available within SuperCollider, such as gtk, > is significant work which will require weeks, if not months. > > 7. I don't like using java for license reasons, performance reasons, > and aesthetic reasons. > > 8. I would like to eventually develop a concise, efficient, and > lightweight alternative. > > 9. In the meantime, I want to use GUI code written by other SuperCollider > users. > > 10. I also want to use code which I wrote while using wmii, under > which java apps functioned properly. > > 11. That means I must use SwingOSC until I have developed an alternative. > > 12. That means I must have java. > > 13. I think dwm is the best window manager for me. > > 14. Therefore, I want to use java and dwm together until I can be free > from java. > > -- > Renick Bell > http://the3rd2nd.com >
Re: [dwm] dietline - minimalistic readline implementation
On Wed, Jan 23, 2008 at 03:13:28PM +0100, Enno Gottox Boland wrote: > Very nice idea. What about collecting all these "baseutilities" and > put them on suckless.org? If we can write more utilities we may get a > complete suckless userspace... :) Sure! When I implement all the basic stuff like nested autocompletions, emacs mode and so I'll publish a working/stable version. A whole suckless userspace would be really cool :) Maybe we can start organizing efforts for implementing it. --pancake
Re: [dwm] [ANNOUNCE] dvtm-0.3
On Tue, Jan 22, 2008 at 06:23:02PM +0100, Fabio Scotoni wrote: > Hello Marc > >>> But it's giving the arrow keys as ^[[A to ^[[D to vim. Good, that's not a >>> big problem, at least, as i can use hjkl, but it would be more >>> comfortable with the arrow keys. >> >> I never noticed this, it seems like the following workaround works in >> the shortterm (colors may be a bit different though). >> >> TERM=linux vim [some file] >> >> vim checks $TERM and does some things differently if it thinks it's run >> from within an xterm or derivate like rxvt which is what madtty/dvtm >> emulates. > DOH! TERM=linux did the trick. Some built-in workaround wouldn't be wrong. Yeah, but i am a bit busy right now and i didn't investigate further for the time being. > For sure, i'm using it with my dwm as replacement for four urxvt's, but > for the console it's a good idea. > > Is there ANY way to check, if dwm/madtty is "hosting"? Not really, what would you like to do depending on that? Regards, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dwm] [ANNOUNCE] dvtm-0.3
On Tue, Jan 22, 2008 at 12:54:52AM -0500, Ritesh Kumar wrote: > Hi Marc, > I just tried out dvtm... its a really nice application of dwm concepts > to the console. Really awesome! Thanks! > I wanted to bounce off a few ideas from the audience about dvtm... > > - We know that dwm uses Mod+ for most of its commonly used actions. > In this case, moving to a given client is basically about pressing Mod and > tapping 'j' a given number of times. However, in dvtm's case, its about > interchangeably tapping ^g and j a number of times... which is not as > smooth. You can always do a ^g n where n is the window number to jump to a specific window. > I know we are trying to minimize interference of shortcuts... and > hence I was thinking, how would it be if we followed a 'command' and > 'insert' mode thing (like vim) for dvtm. I mean, to move to a particular > client and zoom on it we do a ^g ... \n. The \n and ^g keys also > terminate the 'command' mode. A simple notification scheme could be used to > tell the user when he/she is in the command mode. I have thought about this myself, but i think always switching between the different modes is a bit cumbersome. I would like a different (not ^g) keybinding to enter command mode so that a quick ^g + [key] still works. > - What do you think about moving the status bar to the bottom left/right > corner superimposed on the border? I guess using a distinct color (inverse > video with a dark background color) should eliminate any confusion with the > application running in the master window. This will free up the statusbar > line and use the border line without interfering with its function. The statusbar can already be positioned at the bottom (see BarPos in config.h) but it currently doesn't draw over the window border. There are some other ideas floating around, for example Christian Garbs proposed this (the points are the screen borders, only the top and vertical window borders will be drawn): ·· ·-[t1]---· ·· ·· ·-[t2]+-[t3]-· · | · · | · · | · ·· > - Do you think it will be a good idea to terminate dvtm when the last > client is done? I fear accidental shutdowns so much that I generally map the > quit key in dwm to Ctrl+Alt+Shift+q. Quitting after the last client closes > seems to be a cleaner way to shutdown a terminal multiplexer IMHO. As there was some confusion recently regarding the "black window", i will probably commit a solution which quits dvtm if the last client is a shell otherwise a new shell will be opened. Thanks for your comments. Regards, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dwm] dietline - minimalistic readline implementation
I like the sucksless base idea, (and dietline too!) currently I am using plan9 userspace. On Jan 24, 2008 5:38 AM, pancake <[EMAIL PROTECTED]> wrote: > On Wed, Jan 23, 2008 at 03:13:28PM +0100, Enno Gottox Boland wrote: > > Very nice idea. What about collecting all these "baseutilities" and > > put them on suckless.org? If we can write more utilities we may get a > > complete suckless userspace... :) > > Sure! When I implement all the basic stuff like nested autocompletions, > emacs mode and so I'll publish a working/stable version. > > A whole suckless userspace would be really cool :) > > Maybe we can start organizing efforts for implementing it. > > --pancake > >
