Re: Lua..
> "Baawaawaa, it's not written in My Language Of Choice, so > it must be > rewritten." That describes something like 49% of FOSS > projects > The other 49% is "baawaawaa, it's not Freeⓡ: it doesn't > use My > License of Choice". … > The remaining 2% may have some originality. wmii is among that 2%: - it can be scripted in any language, also in your language of choice - it is free from restrictions; you may also sublicense it to your free license of choice ion fulfills neither. I assume you get that 98% of user unsatisfaction, if your 98%/2% numbers are correct. > > It's not imposed. As far as I know, nobody has to use Ion, > as it's > a marginal alternative among a gazillion other window > managers. Exactly. To those who feel too limited by ion's complexity or Tuomo's opinions, I would recommend wmii. I successfully migrated from ion3 to wmii and don't regret it. The migration is easy since they're feature-alike, and it's faster to customize. -- Daniel
Re: License update
--- Tuomo Valkonen schrieb am Mi, 2.9.2009: > Since I probably won't be working on > Ion much, and Ion3 > seems very stable anyway, here's an updated license file > without the 28-day clause. Thanks, one less restriction. I think this is the way to make Ion nicer for developers. In fact I would add just recommendations, instead of restrictions, to a common license. -- Daniel
Re: Abandoning darcs
> Yeah, it sucks.. but it's coming in Linux too. > I absolutely fucking hate the Desktop directory > that every now and then shows up in ~. > IT'S MY HOME DIRECTORY YOU GNOME FUCKTARDS! DON'T PUT ANYTHING > VISIBLE THERE! I'S ***MNE***, NOT YOURS, YOU PIECE OF SHIT > RETARDS!! GET IT?!?!? > No, I don't think they get it... Try in a Gnome discussion list, there may be some Gnome developers there. By the way, is ~ really yours? Who created it? :-) Yes, I also hate it, but I have learnt to ignore it with version control. Or better, I use it to store trash. And if I want a directory that I control myself, I create one, it's not so complex.
Difficulties when running ion on place
Hi, I tried to compile and run ion3 without installing it and I took apparently the painful way. I ended up copying most .lua and configuration files to ~/.ion3/lib just because ion3 was looking for them there and otherwise couldn't find them. (Why can't it try also in the current directory?). Then I found that ion started with a „segmentation fault“ error (more info below). Much later I discovered the cause: there was a file I couldn't copy to ~/.ion3/lib because it wasn't in ion's source. It is look.lua and is created in the etc/Makefile as a symlink to look_newviolet.lua. My request is: instead of creating a link to it at install time, can ion really have a look.lua file which refers (like in #include) look_newviolet.lua? In this way the file doesn't need a special installation step; it is just copied like the others. If not, maybe the defaulting to look_newviolet.lua can be included in the C code, so that if it doesn't find look.lua at least it doesn't crash with a segmentation fault. I would even find better if ion stopped with an useful error message when it can't find look.lua. -- Daniel backtrace: (gdb) run Starting program: /Werkstatt/ion-3-20090110/ion/ion3 [Thread debugging using libthread_db enabled] [New Thread 0xb7d79a70 (LWP 13761)] >> Unable to find 'look' on search path. >> drawing engines loaded, trying "de". >> Unable to find brush for style 'frame-unknown'. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7d79a70 (LWP 13761)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0806e4a7 in grbrush_set_window_shape (brush=0x0, rough=1, n=0, rects=0x0) at gr.c:594
Re: Keyboard focus lost in Swing applications (ex: Netbeans) after changing to window
Sorry for the long wait; I had other compilation problems (I inform briefly about that). > You could, again, try reversing the order of the > finalise_focus and > sendmsg in the TAKE_FOCUS branch of the clientwin focus > function. > That didn't work; with JDK 1.7 it still fails. It must be due to something new of JDK 1.7 since earlier versions work now. Your patch fixed the focus loss in Java 1.6 but makes Java 1.7 applications not receive focus; it is a bug for a bug but I think Java 1.6 apps are more important right now; so I will start using it. -- Daniel
Re: Keyboard focus lost in Swing applications (ex: Netbeans) after changing to window
> > Try the attached patch. (Disclaimer: I haven't particularly tried it; > just quickly threw it together.) Well, it improved lots of things. It works perfectly with gtk, qt, tk, keyboard, mouse, … The example code now works when I use Java 1.6.0_12-b04. But if I compile and run it with the unreleased 1.7.0-ea-b43, the focus is still buggy: not only the text field misses focus after going to that window, but also I can't restore the focus to the text field even if I click into it many times. Even with JDK 1.7, this doesn't happen in other window managers (I tried wmaker).
Re: Keyboard focus lost in Swing applications (ex: Netbeans) after changing to window
Hi; thanks for the helpful explanations.
I tried doing that change and it stayed the same. I also tried doing a
sleep(2) before sending the WM_TAKE_FOCUS (with the +2s timestamp), but without
success.
What did work is this:
static void clientwin_do_set_focus(WClientWin *cwin, bool warp)
{
if(cwin->flags&CLIENTWIN_P_WM_TAKE_FOCUS){
Time stmp=ioncore_get_timestamp();
send_clientmsg(cwin->win, ioncore_g.atom_wm_take_focus, stmp);
} else {
region_finalise_focusing((WRegion*)cwin, cwin->win, warp);
}
XSync(ioncore_g.dpy, 0);
}
I just added the „else“ keyword so that region_finalise_focusing is not
called if the WM_TAKE_FOCUS is sent. I don't know the meaning of this, but only
that it solves all problems with Netbeans and my example Swing application.
Focus is set to the last active widget.
This, however, makes Konqueror 4 stop receiving focus. This makes me think:
- Konqueror has flag CLIENTWIN_P_WM_TAKE_FOCUS and apparently needs both the
WM_TAKE_FOCUS call and the region_finalise_focusing
- Netbeans/Swing also has flag CLIENTWIN_P_WM_TAKE_FOCUS, but if you run the
region_finalise_focusing code on it, it loses focus
Maybe region_finalise_focusing should sometimes be doing nothing in windows
like Netbeans.
Or maybe Swing should be correctly handling the XSetInputFocus(ioncore_g.dpy,
win, RevertToParent, CurrentTime) in region_finalise_focusing.
It is exactly at that XSetInputFocus where the text field at the Swing
application loses the keyboard focus (I tested it inserting sleeps between
calls).
I filed this bug to Sun but I don't know whether they think the bug is in
JDK. The bug report is at http://bugs.sun.com/view_bug.do?bug_id=6798064
Greetings,
Daniel
Re: Keyboard focus lost in Swing applications (ex: Netbeans) after changing to window
Daniel Clemente writes: > > I will check it again in other systems. Hi, I tried it with Sun's Java 1.6.0_10 on Debian (another machine). The bug is still present. However, on the same machine, Sun's Java 1.5.0_16-b02 makes my example work as expected (focus is not lost). And with libgcj... well, the example didn't work correctly and I didn't see the text field. My version: java version "1.5.0" gij (GNU libgcj) version 4.3.3 20090110 (prerelease) With OpenJDK 1.6.0_0-b11, the bug shows up. With the unreleased Java 1.7.0-ea-b43, the same (bug present). So the focus problem seems to be a regression introduced in version 1.6 of Java and still not corrected... Or maybe it is indeed a bug in ion3; since other window managers (ex: icewm) do work with Java 1.6. In any case, I sent this bug to Java (sorry, it's not public yet). I will report progress here. -- Daniel
Re: Keyboard focus lost in Swing applications (ex: Netbeans) after changing to window
Tuomo Valkonen writes: > On 2009-01-15, Daniel Clemente wrote: >> In fact any Swing application has this problem. > > Tried; works for me. I was using Ubuntu GNU/Linux 8.04.1 with these packages: ii linux-image-generic2.6.24.21.23 Generic Linux kernel image ii sun-java6-bin 6-06-0ubuntu1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent fil ii xorg 1:7.3+10ubuntu10.2 X.Org X Window System I will check it again in other systems.
Keyboard focus lost in Swing applications (ex: Netbeans) after changing to window
Hi, sorry if this message comes twice (I posted yesterday via NNTP without
being subscribed to the list).
ion3 is stealing keyboard focus to Swing applications. This happens for
instance with Netbeans 6.5:
1. Open netbeans and some other programs in tabs next to it.
2. Select netbeans and open an editor with some code; the cursor is inside the
editor
3. Select another tab (either clicking teh tab or with keyboard).
4. Select netbeans again (either clicking the tab or with keyboard).
5. Try to continue typing, but you can't. The cursor is nowhere, and *no key*
works (space, cursors, A-S-o, ... all gone). You must click again in the editor
and then you can type again.
In fact any Swing application has this problem. You can use this one to test:
--- TypeInSwing.java
import javax.swing.JFrame;
import javax.swing.JTextField;
public class TypeInSwing {
public static void main(String[] args) {
JFrame frame = new JFrame("HelloWorldSwing");
final JTextField field = new JTextField("type here");
frame.getContentPane().add(field);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
}
--
It happens with latest version 20090110 (with 20080207 too).
I am using:
$ java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
Why is it so?
Daniel
Re: Disable automatic saving of workspace (frame layout)
Tuomo Valkonen <[EMAIL PROTECTED]> writes:
> Exit with ioncore.resign() instead of ioncore.shutdown()
The session is saved not only on exit but also on restart:
/*EXTL_DOC
* Restart, saving session first.
*/
EXTL_EXPORT
void ioncore_restart()
{
set_other(NULL);
if(smhook!=NULL){
smhook(IONCORE_SM_RESTART);
}else{
ioncore_do_snapshot();
ioncore_do_restart();
}
}
The restart will save the session unless the source code is modified. Or
maybe it can be overriden in Lua?
Daniel
Disable automatic saving of workspace (frame layout)
Hi. Here: http://www.modeemi.fi/~tuomov/ion/faq/entries/Saving_layout.html it says: -- How do I save workspace and frame layout? Ion does it automatically for you when you exit it cleanly. -- Can ion be configured not to do this? I would like to read my layout always from saved_layout.lua but not save it automatically on exit. I will save it manually when I want. Thanks Daniel
Re: Move frames to and from scratchpad
Hi,
Canaan Hadley-Voth <[EMAIL PROTECTED]> writes:
> I have been using this function to do what you are trying to do. (Though
> someone else might anticipate further cases where mine also fails, like a
> WClientWin attached (unframed) to a WGroupWS.)
>
> function send_to_or_from_sp(cwin, jumpto)
> local sp=ioncore.lookup_region("*scratchpad*", "WFrame")
> if cwin:parent()==sp then
> local scr=cwin:screen_of()
> local destws=scr:mx_current()
> local destwstype=obj_typename(destws)
> if destwstype=="WTiling" then
> destws:current():attach(cwin)
> elseif destwstype=="WGroupWS" and
> obj_typename(destws:current())=="WTiling" then
> destws:current():current():attach(cwin)
> elseif destwstype=="WGroupWS" then
> destws:attach_framed(cwin)
> end
> mod_sp.set_shown_on(scr, 'unset')
> else
> sp:attach(cwin)
> end
>
> if jumpto then
> cwin:goto()
> end
> end
>
I have been using the function you sent and it works very well; thanks.
With Tuomo's improvements, I think it would be very helpful for the
scratchpad feature of Ion. Could it be included?
-- Daniel
Re: Move frames to and from scratchpad
Tuomo Valkonen <[EMAIL PROTECTED]> writes:
> Your _ probably points wrong, i.e. your in the wrong bindings section.
> _:screen_of() should always give the screen. (Note that it's shorter
> to call _:mx_current() or _:screen_of():mx_current() than to type the
> full function names.)
>
After trying several combinations, I found one that correctly brings a frame
from scratchpad to the background frame:
In Lua console:_:screen_of():mx_current():current():current():attach(_sub)
In a key binding: kpress(META.."Shift+k",
"_:screen_of():mx_current():current():current():attach(_)"),
Note the difference between _sub and _. So yes, my _ was wrong.
So the current working set of keybindings for my proposal is:
defbindings("WClientWin", {
kpress(META.."k", "WMPlex.attach(ioncore.lookup_region('*scratchpad*'),_)"),
kpress(META.."Shift+k",
"_:screen_of():mx_current():current():current():attach(_)"),
})
Maybe this needs some tweaks, for instance: when I move to scratchpad and the
open the scratchpad, I expect to find the moved frame selected; without having
to move to the right of the active on.
Also I would like to use a single key instead of no: If the scratchpad is
open, do one thing. If it is closed do another
Is this useful for other people? How would you improve it?
Thanks
Daniel
Re: Move frames to and from scratchpad
Hi,
I start with the easy one.
>> - If the scratchpad is not open, then move the current frame to the
>> scratchpad. Don't open the scratchpad
> This should be rather easy. Just use ioncore.lookup_region to find one named
> "*scratchpad*", and use WMPlex.attach on it.
I tried:
WMPlex.attach(ioncore.lookup_region("*scratchpad*"),_sub)
And it works very well. When I assigned it a key binding, at first it didn't
work, but it was because I was using a WScreen binding instead of a WClientWin
binding. I corrected that and this is the working code:
defbindings("WClientWin", {
kpress(META.."k", "WMPlex.attach(ioncore.lookup_region('*scratchpad*'),_)"),
})
> If there are multiple scratchpads (such as when there are multiple screens),
> one may have to choose between them, numbered in the typical fashion
> (*scratchpad*, *scratchpad*<1>, ... etc., but with guaranteed correspondence
> to screen numbers). In that case ioncore.region_i may be better. One can also
> cache them in variables the script to not have to look them up all the time.
> (obj_exists is then useful to check that the scratchpad is still there). An
> alternative to the global scanning functions in ioncore. is to use
> WScreen.mx_i, which is also what the modules does (essentially, but in C).
I'll leave the „multiple scratchpads“ part since I always have one and it
seems harder to do.
I noticed that what you propose is similar to this code:
http://modeemi.fi/~tuomov/repos/ion-scripts-3/scripts/cwin_sp.lua
>> If the scratchpad is open, then move the current frame (inside the
>> scratchpad) to the window below the scratchpad. Don't close the scratchpad
> Perhaps easier would be to use the screen's mx_current object, which is
> typically the current group, and then recurse WRegion.current until it
> produces a frame and use that as the target (or the last frame seen until the
> recursion returns no result). The result should typically be the frame that
> was last active on the current workspace.
Yes, I meant that. Not geometrically (since below the scratchpad there may be
more than 1 target) but just the last active window (in before the scratchpad
was open.
This seems to work to move from scratchpad to a particular frame:
WMPlex.attach(ioncore.lookup_region('WFrame<1>'),_sub)
However, I don't know how to get the current „background“ group while I'm on
the scratchpad. I tried your proposal, WScreen.mx_current(_), but for me
WScreen.mx_current(_).name(_) while I'm in scratchpad returns just
„*scratchpad*“ and not the name of the frame below. I'm probably not
understanding the theory.
Could you please provide some example code for this one?
Thanks,
Daniel
Move frames to and from scratchpad
At any moment, a frame is either in the scratchpad area (Mod1+Space) or not. I would like to have a single key which commutes between the two states. It would do this action: - If the scratchpad is open, then move the current frame (inside the scratchpad) to the window below the scratchpad. Don't close the scratchpad - If the scratchpad is not open, then move the current frame to the scratchpad. Don't open the scratchpad In both cases, that key would make a frame quickly „disappear“. A single key works for both actions A use case is: When moving TO scratchpad, you're asking the frame to go away because you have to work with more important frames. At the scratchpad you find always the unimportant frames. Pressing that same key again you can place them back in the main area. I haven't succeeded in coding it (actually I found ion3 very complex to grasp and extend). How can this function be programmed? Thanks, Daniel
Open frame to the right of the parent window
Hi, there's just one thing I still couldn't configure in ion3, namely a solution to cases like the following: - a slow program will open shortly in workspace 3, and I must stay waiting at workspace 3 because I want it to be really in workspace 3 (and no other) when it pops up - I am in workspace 2, and a program in workspace 3 opens a window. The window shows up in the current workspace 2 and interrupts what I was doing The problem is just one: when a new window was opened from a frame which is not the current one, the window opens up in the current frame instead of in the original one. You can reproduce this by issuing „sleep 2; xeyes“ from a terminal, then switching to another workspace. The behavior I want is that the window opens in the tab to the right of the tab of the parent window. By „parent window“ I mean the window which decided to open the new one. There is a variable for controlling where to open new frames: -- Default index for windows in frames: one of 'last', 'next' (for -- after current), or 'next-act' (for after current and anything with -- activity right after it). --frame_default_index='next', I suggest adding a parameter frame_default_index='parent-next' or similar to mean „after the window who issued the request (even if it's in another frame)“. Note that if switchto=true, then the focus could switch to other frame/workspace just because a new window opened up there. Another parameter might be needed to mean „switchto=true, but only if it doesn't imply moving the focus to another frame or workspace“. What do you think? Thanks, Daniel __ Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
