The euclid-wm thread

Hi all.
I wanted to announce a new tiling window manager that is currently under development: euclid-wm.
It is hosted on googlecode, and is currently available via svn:
http://code.google.com/p/euclid-wm/
The arch linux forums seem to have a lot of tiling wm types so I thought this would be a good place to look for people who might be interested in giving it a test drive.
Obviously any feedback would be very much appreciated.
Thanks.
Cheers.
Last edited by wmdiem (2011-12-15 00:42:19)

@Aedit: "Nice to see another tiling wm. I rather like the window move and resize functions."
Thanks!
"a vertical move cannot move a window into a new row, but a horizontal move can create a new column. As far as I can see, there is no reason for not allowing it."
The behavior you describe (if I follow you) is exactly what I originally envisioned. Unfortunately (maybe I'm brain dead) but I couldn't figure out a non-clunky way of doing it. Essentially the problem comes down to what the intuitive behavior becomes once you allow mixing horizontal and vertical tracks in a single layout. If someone can think of a good way of implementing this (with well defined intuitive behavior after the horizontal and vertical are mixed and nested) I would be quite willing to try to implement it. But I tried once, gave up, and rewrote it as it is. The current behavior is a sort of workable compromise.
"You could build more usability into the default layout creation. If I open 3 terminals in a row I almost never want them arranged according to your default (3 one above the other)"
I've thought of doing this (it wouldn't be hard), but it hasn't worked it's way up on the priority list yet. My reason for not worrying about it is just that moving windows is easy.
"In /usr/share/xsessions/euclid.desktop Exec=start-euclid should be Exec=euclid-wm."
Yes, start-euclid no longer serves a purpose and will be removed unless and until I find a need for a wrapper.
"After rotating (Alt+Tab) the Alt+H/L keys are the wrong way round"
Will fix. This whole opening it up to testing has been really humbling. I've had more facepalm/what-were-you-thinking/how-did-you-miss-that moments in the last 48 hrs than I thought I ever could. Thanks for catching it.
"Are transient windows just treated like other windows?"
yes. I spent a considerable amount of time trying to figure out what to do with transient windows. Finally I decided that if I really bought the whole "floating windows don't belong" thing then it applies to transients too (as an example: sometimes when i'm looking at a save dialog I want to be able to see the main window, e.g., to remember what I'm saving). That said, they don't always cooperate (I'm looking at you Chrome).
"In the man page the keybinding for toggle stack visibility should be M+space not M+shift+space"
Will fix it, thanks for noticing.
"The line system("x-terminal-emulator &"); should be system("xterm &");"
Why's that? At least on Debian, xterm is an actual executable (that many people don't like to use), x-terminal-emulator is a link that the user can point to whatever emulator he likes. The real solution to this will come when I write a config, then the user can point to anything he wants.
"There are a lot of source code lines containing just tabs or ending in spaces. It would be good to clean them up."
Yeah, the source is a mess right now. It's on the list. 
"Also there are a bunch of unnecessary files pulled in by the PKGBUILD to the src directory."
The PKGBUILD is very kindly maintained by BKLive above. 
"Looking forward to a text config file and a status bar."
*grimmace* I'll get down to the config once the deluge of bugs clams down. I'd really like to do the status bar as a separate executable. If I did, it would come with the whole issue of how to handle dock-type apps, which I've been thinking about, but haven't yet resolved.

Similar Messages

  • Not Running on the Event Dispatch thread, but UI still freezes

    The environment: I am currently working on an application that requires some heavy lifting in response to user input on a UI. To do this I am using a version of SwingWorker that was backported from java 1.6 to java 1.5 in conjunction with a slew of custom threads.
    The problem: I am currently running into an issue where I am not operating on the Event Dispatch thread (checked by doing a javax.swing.SwingUtilities.isEventDispatchThread()) but the UI is still freezing during this section. The operation involves a loop with about 2000 iterations and contains several file accesses. I have thought about how to make a new thread to perform the same operation, but I do not see how it would be any different since as it is I am not on the EDT. The call is being made from doInBackground and specifically the piece that is slowing things down is the File Accesses (2 for every iteration of the loop). At this point I am not sure how to go about resolving the issue. Any one have any suggestions?

    I am not operating on the Event Dispatch threadThat is the problem. Use multiple threads for GUI, which should delegates to the EDT, and your app logic.

  • Is there a way to view earlier messages in a thread without going through each day? Also, can you make a photo album from the same text thread without going back to the beginning?

    Is there a way to view earlier messages in a thread without going through each day? Also, can you make a photo album from the same text thread without going back to the beginning?

    Turn Settings > General > Accessibility > Zoom to ON.

  • Is the Memory Suite thread safe?

    Hi all,
    Is the memory suite thread safe (at least when used from the Exporter context)?
    I ask because I have many threads getting and freeing memory and I've found that I get back null sometimes. This, I suspect, is the problem that's all the talk in the user forum with CS6 crashing with CUDA enabled. I'm starting to suspect that there is a memory management problem when there is also a lot of memory allocation and freeing going on by the CUDA driver. It seems that the faster the nVidia card the more likely it is to crash. That would suggest the CUDA driver (ie the code that manages the scheduling of the CUDA kernels) is in some way coupled to the memory use by Adobe or by Windows alloc|free too.
    I replaced the memory functions with _aligned_malloc|free and it seems far more reliable. Maybe it's because the OS malloc|free are thread safe or maybe it's because it's pulling from a different pool of memory (vs the Memory Suite's pool or the CUDA pool)
    comments?
    Edward

    Zac Lam wrote:
    The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences.  If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
    When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage?  Are you getting any error code returned from the function calls themselves?
    I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
    There is no error return code from the ->NewPtr() call.
         PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
    A NULL pointer is how you detect a problem.
    Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
    btw my NewPtr size is either
         W x H x sizeof(PrPixelFormat_YUVA4444_32f)
         W x H x sizeof(PrPixelFormat_YUVA4444_8u)
    and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
    The more processing power that the nVidia card has seems to make it fall over faster.
    eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
    I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.

  • How to find out the number of threads created under java vm at runtime

    our application seems to have hit the max number of threads that can be created under vm and the vm will just hang after that. that behavior seems to be consistent from an article that I read earlier.
    I wonder any way that java app can find out the number of threads currently created under vm?
    thanks in advance!

    If you are not starting an extra thread group you can use the Thread.activeCount method. But this willnot return all the threads, as there are some jvm threads, i.e. garbage collector. Also if you are running on a Unix type operating system then you can send a signal to the jvm to give you a thread dump, i think the signal is sighup.
    If the application is hanging i would of thought that you have a deadlock situation rather then the JVM not being able to create new threads, roughly how many threads should be running ??

  • How do I control the number of threads?

    I'm currently writing parts of a GUI front-end in Swing for an extremely resource-hungry C back-end. I built the thing out on the basic two-thread (main and event) protocol that all of the literature talks about. The initial plan was to have a number of somewhat different versions of this thing being called independently to serve as micro-GUIs for different parts of the back end. It was working pretty well by itself, but it caused some noticeable slowdown in the main program once I tried to bring up two of them, and some thread-tracking software has informed me that each of these calls is costing me on the order of 27-28 threads. Is there anything I can do about this thread count? Is it normal? Would building all of the versions into a single .jar with internal switching at least limit the damage? If it's not normal, what should I be looking for to bring it back down? I have not explicitly spawned or dealt with any threads other than main and event.
    If it is any help, the basic format is a JFrame containing a number of JPanels, some of which have a few subpanels. Some of the panels are swapped in and out of visibility by button presses. If the JPanels are somehow automatically creating event threads for themselves, is there any way I can limit that, perhaps by forcing them to use the event thread of the parent?
    Thank you for your time.
    Fibula

    IF you're talking GUI, and you were, yes you can definitely reduce thread count by running everything in the same jvm

  • How do you modify the default Execute thread count in Weblogic Server 9.2?

    How do you modify the default Execute thread count in Weblogic Server 9.2?
    How can you tune the starting number of weblogic.ExecuteThread on server startup and/or set minimum number?
    Is there an option from the console?
    Please let me know.
    Thanks

    Self tuning will automatically manage the threads but however you can still control the min and max by adding the min and max values for each instance either directly adding in config.xml or through JVM settings
    1) Modifying the config.xml
    Just add the following line(s) to each server definition :
    <server>
    <name>AdminServer</name>
    <self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min>
    <self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max>
    </server>
    2) Adding some JVM parameters
    It's safer the following way :
    add the following option in your command line : -Dweblogic.threadpool.MinPoolSize=100
    Regards
    RR

  • What's the maximum # of threads?

    Support for asynchronous I/O (in HTTPService and WebService)
    kinda implies that the Player has a thread pool that it gets a
    spare thread from each time I do a send() on one of these
    components. Each allocated thread will block until it gets a
    response. If I don't get any responses (perhaps because it's
    long-lived) how many threads can I obtain from the pool before the
    Player runs out of threads (or is there no maximum or is it a
    start-up parameter)?

    Anakin1989 wrote:
    Hi,
    I'm working on a pretty big program and i need a lot of threads to make it run well (it's an audio player and, of course, i don't need people to wait when, for example, they save a playlist). So, i put some of these tasks on different threads, plus others that i didn't need for making the program run faster, but they are there just to make the program run. Now i have at least 4 threads running at the same time and, in some cases, there are even 6 or 7. Is it too much? It's my first big program (it's just for fun but i still want it to run well) and i didn't need so many threads before. What's the maximum number of threads you'd recommend me to have?
    Thanks.Are you experiencing any problems with the number of Threads you have? If not, stop worrying. On the other hand, are you sure you need all of them? There are alternatives to Threading, such as SwingWorker and Timer that might be able to help you out.
    One thing you better make sure of is that you're not doing any Swing work off of the EDT, or doing things like sleeping or time-consuming work on the EDT.

  • ..this method should be invoked from the event-dispatching thread?

    I see this (the title that is) in every single Java demo/example program on this (Sun's) site. However, I just tend to
    public static void main(String[] args){
       new whateverTheClassIsCalled();
    }And I've seen this approach on other sites and other example programs.
    So what exactly is better about this;
        public static void main(String[] args) {
            //Schedule a job for the event-dispatching thread:
            //creating and showing this application's GUI.
            javax.swing.SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                    createAndShowGUI();
        }where createAndShowGUI() sets and packs the frame. I just do all this in the class constructor (when it's a JFrame!)
    So what does all this thread dispatching stuff mean, why should I use it etc etc.
    tia.

    Is it just me? For some reason it rubs me the wrong way that swing isn't thread safe. From what I've read, my understanding is that its safe to modify swing components from other threads as long as they haven't asked to be painted. If you don't do paint(), pack() or setVisible(true) until the end of your initialization, you will be safe.
    The reason for not being thread safe is almost certainly performance. Swing is slow enough as it is. Since the vast majority of Swing activity takes place in response to events and thus is on the EDT, there usually isn't a problem.
    This is a serious nuisance in network and database programs where multiple threads are used. I end up using invokeLater a lot in those cases, but never for initialization. Sun has only started to recomment that recently.
    Note that the fireXXX methods do not put the event on the EDT, these simply create Event objects and send them to Listeners. If they are executed off the EDT the Listeners will get called off the EDT.

  • Are methods in the Graphics class Thread Safe

    Can methods from the Graphics class (.e.g. drawImage(), drawString(), ect..) be called from any thread? In other words, can two threads that refer to the same Graphics object step on each other methods calls?
    TIA,
    DB
    Edited by: Darth_Bane on Apr 27, 2009 1:44 PM

    No,
    They are GUI activities so you should call them from the Swing Thread ( Event Disptach Thread)
    Now for the JComponent the following are thread safe:
    repaint(), revalidate, invalidate which can be called from any thread.
    Also the listener list can be modified from any thread addListenerXX or removeListenerXX where XX is ListenerType
    Regards,
    Alan Mehio
    London, UK

  • Executing Code outside of the Event Dispatcher Thread

    Hello,
    I have just come to learn that any actionPerformed() method that is called after an event occurs actually runs in the Event Dispatcher. So, for example, if you click on a button, any code that is run as a result is run in the event dispatcher.
    So there are two things I am wondering about. First, If i run code in response to a user event, then it doesn't have to use invokeLater() to update GUI components because it's already being run in the event thread? Second, if I run code in response to an event but it's computationally expensive and I do not want to run it in the Event Dispatcher thread, how do i do that? Will a method call cause it to do so, or do i have to specifically create a new thread for it?
    My questions are a result of this: How does one normally go about updating a GUI during a long process? I figured that if I could get the process to run in any thread other than the Event Dispatcher, I could call invokeLater() within it and it would update the GUI. Am I correct in assuming so?

    So there are two things I am wondering about. First, If i run code in response to a user event, then it doesn't have to use invokeLater() to update GUI components because it's already being run in the event thread?
    Correct. So if your response to an action is, for example, creating a new bit of UI using data which is already in memory, you can just do it.
    Second, if I run code in response to an event but it's computationally expensive and I do not want to run it in the Event Dispatcher thread, how do i do that? Will a method call cause it to do so, or do i have to specifically create a new thread for it?
    You will need to create a new thread: method calls are just control flow within the same thread.
    You should use an object which implements Runnable and then use "new Thread(foo).start()"
    My questions are a result of this: How does one normally go about updating a GUI during a long process?
    You have to hop back onto the EDT whenever an update is required. I'd suggest writing yourself a little reusable class or two to help you with this - such as a listener mechanism with an implementation which handles the thread hopping.
    I figured that if I could get the process to run in any thread other than the Event Dispatcher, I could call invokeLater() within it and it would update the GUI. Am I correct in assuming so?
    Yes.
    Should I use inner classes? I would prefer to keep them as separate classes within the same package.
    Depends on all sorts of things - sometimes anonymous or declared inner objects are the way forward, sometimes public class objects, sometimes generic helper objects and sometimes utility classes. There are all sorts of different scenarios. As I say, though, it's worth writing some utility/helper classes to reuse. Personally I don't find SwingWorker is ideal so I have my own. Note that an abstract Action implementation is a very useful one, since this is precisely where you need to be doing most of the thread hopping.

  • Interpretation of the use of threads with Sessions in the JMS Specification

    Hello,
    I’ve been interacting with two JMS Providers which do a different interpretation of the JMS Specification with the use of different threads for accessing to a session and session’s related objects.
    The question is:
    When a client is consuming messages asynchronously, is it possible to access session’s related objects from a thread different to the one dedicated to the asynchronous consumption, on (thread of control)?
    -     Never?
    -     Yes, but the client should provide explicit synchronization.?
    Our execution scenario is:
    1.- Messages are consumed asynchronously from a dedicated thread.
    2.- From other thread, messages consumed are acknowledged.
    In the JMS specification there is, at least, two parts where this issue is treated:
    1.- The first one (4.4.1 - page 60):
    +“There are no restrictions on the number of threads that can use a Session object or those it creates. The restriction is that the resources of a Session should not be used concurrently by multiple threads. It is up to the user to insure that this concurrency restriction is met. The simplest way to do this is to use one thread. In the case of asynchronous delivery, use one thread for setup in stopped mode and then start asynchronous delivery. In more complex cases the user must provide explicit synchronization.”+
    This extract, makes me think that it is possible the access from different threads, but If I do that, I should provide explicit synchronization.
    2.- The second one (4.4.6 – page 62,63)
    +"Once a connection has been started, any session with a registered message listener(s) is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this is the use of the session or connection close method"?+
    This extract, could be interpreted as that the concurrent access is never allowed in the described situation.

    I think the key words are in 4.4.6 (and also the javadoc for Session): "Once a connection has been started, any session with a registered message listener(s) is dedicated to the thread of control that delivers messages to it".
    My interpretation of this is that you when you register a message listener and call connection.start(), the thread which delivers messages to the listener should be thought of as "using the resources of the session" (as mentioned in 4.4.1) continuously until the connection is stopped (or until the session or connection is closed). it doesn't matter whether the session is executing onMessage() or not.
    Given this, both 4.4.1 and 4.4.6 say the same thing: that once you have registered and started a message listener, the only thing you can do to the session from another thread is to close it.
    I agree the spec could be clearer. In particular the words "In more complex cases the user must provide explicit synchronization" in 4.4.6 should be clarified to state what this actually means rather than give a hint.
    Please note that work has just started on updating the JMS specification, so now is a great time to report areas of the JMS spec which would benefit from clarification. If you'd like this to be considered for clarification, please report it in the official JSR 343 issue tracker at http://jms-spec.java.net
    Nigel

  • Unable to delete the Redolog of Thread 2 in RAC

    Hi,
    Oracle 10gR2 ( 10.2.0.4), Rac Environment, Instance name orcl1, orcl2
    Recently the orcl2 got crashed so we rebuilt the machine and orcl2 node and added the node again back to cluster
    There was a failed attempt in DBCA (Addition instance part) where the redolog05 & 06 got created in ASM.
    We created instance orcl02 as thread 3 instead of thread 2 and successfully added the node to cluster.
    The redolog of thread 2 (redo05, redo06) created due to the failed DBCA add instance activity in unable to delete from the v$log entries.
    GROUP# THREAD# MEMBER ARCHIVED STATUS Size (MB)
    1 1 +ORCLDG3/orcl/redo01.log YES ACTIVE 50
    2 1 +ORCLDG3/orcl/redo02.log NO CURRENT 50
    5 2 +ORCLDG3/orcl/redo05.log YES UNUSED 50
    6 2 +ORCLDG3/orcl/redo06.log NO CURRENT 50
    8 3 +ORCLDG3/orcl/redo08.log NO CURRENT 50
    9 3 +ORCLDG3/orcl/redo09.log YES INACTIVE 50
    When i tried to disable the thread 2 i am getting the below errors, as the redo log 05, 06 are not physically present in the ASM
    SQL> alter database disable thread 2;
    alter database disable thread 2
    ERROR at line 1:
    ORA-00313: open failed for members of log group 6 of thread 2
    ORA-00312: online log 6 thread 2: '+ORCLDG3/orcl/redo06.log'
    ORA-17503: ksfdopn:2 Failed to open file +ORCLDG3/orcl/redo06.log
    ORA-15173: entry 'redo06.log' does not exist in directory 'orcl'
    Please help in removing the Thread 2 redo log files as this warning are getting written in the alert log every second and fills the mount point.
    Regards

    The method suggested in the thread is not working, please find the below errors,
    SQL> alter database clear logfile group 5;
    SQL> alter database clear logfile group 6;
    alter database clear logfile group 6
    ERROR at line 1:
    ORA-00350: log 6 of instance orcl2 (thread 2) needs to be archived
    ORA-00312: online log 6 thread 2: '+orclDG3/orcl/redo06.log'
    SQL> alter database drop logfile group 5;
    alter database drop logfile group 5
    ERROR at line 1:
    ORA-01567: dropping log 5 would leave less than 2 log files for instance orcl2 (thread 2)
    ORA-00312: online log 5 thread 2: '+orclDG3/orcl/redo05.log'
    SQL> alter database drop logfile group 6;
    alter database drop logfile group 6
    ERROR at line 1:
    ORA-01623: log 6 is current log for instance orcl2 (thread 2) - cannot drop
    ORA-00312: online log 6 thread 2: '+orclDG3/orcl/redo06.log'
    SQL> alter database disable thread 2;
    alter database disable thread 2
    ERROR at line 1:
    ORA-00313: open failed for members of log group 6 of thread 2
    ORA-00312: online log 6 thread 2: '+orclDG3/orcl/redo06.log'
    ORA-17503: ksfdopn:2 Failed to open file +orclDG3/orcl/redo06.log
    ORA-15173: entry 'redo06.log' does not exist in directory 'orcl'
    Any ideas,

  • Future.get and the event despatch thread blocking

    neeeyaaarghhhh
    been tying myself in knots thinking about this
    Following one of the java tech tips I've been using Callable and Future objects when I want to return a result from a task, in my case it's usually some file processing
    So I have a file chooser gui, I select a file and launch my Callable and await the result in Future.get...
    Now the problem is... Future.get I understand blocks the calling thread until the computation / work in the Callable is done and the result returned. In this case the blocked thread will be the event despatch thread... which causes problems as during my file reading I have a JProgressBar running and updating. Well at least I did, now it doesn't show up at all as all the updates to the JProgressBar via invokeLater are queued (as event despatch thread is blocked) until after the work thread has finished
    How do I launch a Callable, await the result and have some limited gui activity as the task progresses? The only solution I've found is to have the ProgressBar in a modal dialog, to block out the rest of the gui like this whilst I do the work in the event despatch thread (and drop the idea of threading altogether)
    Is my mental modal of how worker threads should spin off from the event thread flawed or am I just missing some 1 line command?

    In the situation of updating the gui, you usually want to pass some sort of callback object to the asynchronous code and have that callback method run on the gui event thread.
    public class GuiClass {
    public void handleResult(Object data);
    public void startTask() {
      threadpool.execute(new Runnable() {
        public void run() {
          // ... do asynch work ...
          final Object myResult = ...;
          SwingUtilities.invokeLater(new Runnable() {
            public void run() {
              handleResult(myResult);
    }In this code, the startTask method is called on the gui thread. it starts some async work on the threadpool. when finished, the asynch task queues the result to be handled back on the gui thread. the handleResult method is called later on the gui thread with the final result. thus, no blocking of the gui thread.
    The Callable interface is great for when the invoking thread needs to wait for a result, but you pretty much never want to do this with the gui thread.

  • How to use the sleep and thread?

    I'm coding a program to move a player on the screen,
    but the program directly run to the end,
    the animation part dose not display,
    how can i modify my code to show the movement of the player?
    here is the run function,
    Thread t, w;
    public void run() {
         while (isClick) {
              try {
                   repaint();
                   t.sleep(500);
                   int j = playerStep + 40;
                   while(playerStep < j) {
                        try {
                             playerStep += 10;
                             repaint();
                             w.sleep(300);
                        } catch (InterruptedException err) {
                             JOptionPane.showMessageDialog(null, "Moving error!");
              } catch (InterruptedException err) {
                   JOptionPane.showMessageDialog(null, "Drawing error!");
              isClick = false;
              repaint();
    }Thanks a lot.

    what is the value of isClick variable when your program is starting?

Maybe you are looking for