[Geany-Users] status bar and commands lock

Wed Jul 26 16:51:24 UTC 2017

The background for all this:

I did not t run into this very often in the past.

I have about 40 library sets that I compile into static libs. A library is
one profile set. 10 minimum to about 35 on a largest set, usually in at
least three directories. (I made a build system that keeps everybody in its
proper place - but this means a couple more files per lib.) After a library
is stable, I don't touch it again.

For current work, I have a script system that brings up the sets of
programs and libraries that I am working on currently. This script set also
brings up the needed consoles on each desktop for each particular
program/libray I am working on. These consoles are opened outside of geany.
Any one library I work on may need 3 to 5 other profiles opened so I can
keep everything correctly referenced without opening and closing, opening
and closing again and again. (I'm old - I doubt my memory sometimes, these
days.)

Every so often, I need to go back and adjust an old library (recently, for
mutlithreading changes, for example.) I never made a script for those older
libraries.
In this instance, I bring those profiles up on a clean system manually, and
start the consoles from geany. This is when I have these problems
frequently.

Even on the new scripts, especially because of threading issues, I
sometimes bork a console, need to close it, and open a fresh console. This
is when I first started to notice this problem, but didn't worry about it.
Now that I am going back to some of the old libs to make changes, I am
hitting this very frequently.

The scripting for multiple sessions and opening the consoles is relatively
new - no more than 2 years old. Previously, every session was opened
manually, with its consoles from inside geany. I never had this problem,
then.

One of those scripts, and one library profile is attached for your info.
The rdkl directory is on a remote server. This and any system I work on or
edit with are in my home.

David

On Wed, Jul 26, 2017 at 8:45 AM, David Barnes <dnsenrab at gmail.com> wrote:

> Yes, more than one session of geany.
> NOT completely independent.
>
> ---------------------
>
> A circumstamce:
>
> Several geany sessions opened - mulitple files open in each with no files
> opened in more than one session.
>
> No activity in ANY geany instance.
>
> Open a console in one session, for example on desktop 2.
>
> Another session - maybe desktop 6 - shows the activity status with that
> sessions's build menu blocked.
> Close the console, indicator and build menu released.
>
> When I tested this yesterday, I had no other user programs of any kind up
> after a clean boot.
>
> --------------------
>
> Yes, did try the '&' terminator on the command - no difference.
>
> My new solution: one session I typically open is a reference only session:
> I rarely need to edit there. I pop open consoles there until I get the
> lock, then I can use the other sessions. NOT elegant.
>
> I understand about mixed messages and confused sources/destinations in an
> OS. But this means that geany is listening for any message to any geany -
> even when no build menu item - or any action - was requested. Is THAT
> happening? I thought the messaging systems all had client identifiers to
> keep things seperated.
>
> A thought: I imagine geany does broadcast messages that files have been
> changed, and every instance does need to listen for that. Perhaps there is
> a misidentification of the activity there.
>
> version: "Rezer"
> (built on or after 2016-04-17)
>
>
> David
>
> On Wed, Jul 26, 2017 at 1:54 AM, Lex Trotman <elextr at gmail.com> wrote:
>
>> On 26 July 2017 at 17:48, David Barnes <dnsenrab at gmail.com> wrote:
>> > By the way, only ONE session gets locked up. Never noticed more than
>> one, no
>> > matter how many more sessions or consoles are opened, or opened and
>> closed.
>>
>> When you say "session" what do you mean? Do you mean you are running
>> multiple instances of Geany?
>>
>> If so then they are completely independent processes, so running a
>> blocking command in one instance will have no effect on the other
>> instances.
>>
>> Because the output of build commands is parsed and displayed in the
>> compiler output tab only one build command can be running at a time or
>> their output will get mixed up and confused.
>>
>> So the build menu is blocked whilst a command is running.  So as I
>> said before, the command needs to start your terminal as a detached
>> process and exit immediately to get the menu back.  Did you try using
>> &? On *x commands are run in sh so it should work.
>>
>> >
>> > On Wed, Jul 26, 2017 at 12:30 AM, David Barnes <dnsenrab at gmail.com>
>> wrote:
>> >>
>> >> Yep. If I start a console from a geany session, that 'process busy'
>> >> indicator will show up - somewhere. I open at least three sessions
>> anytime I
>> >> work. Any one of them may have that indicator, and consequently, the
>> build
>> >> menu greyed out. When I close the console, it clears.
>> >>
>> >> A typical project session will have files sourced from as many as four
>> >> different directories. That means, I might want to open 4 consoles,
>> though
>> >> usually it is just 2.
>> >> For most sessions, I automatically open 2 consoles. Since this can lock
>> >> one geany build menu in some **other** geany session on a different
>> desktop,
>> >> I would have to close all the consoles to find the offender. That
>> could be
>> >> ten consoles to drop before I find which is the problem.
>> >>
>> >> This was not a problem in the past. I never saw that indicator in the
>> >> past.
>> >>
>> >> Now - this is a deal breaker.
>> >>
>> >> Can that process busy indicator be supressed?
>> >>
>> >> David
>> >>
>> >>
>> >> On Sun, Jul 23, 2017 at 6:08 PM, Lex Trotman <elextr at gmail.com> wrote:
>> >>>
>> >>> On 24 July 2017 at 06:33, David Barnes <dnsenrab at gmail.com> wrote:
>> >>> > Thank you for the quick reply.
>> >>> >
>> >>> >
>> >>> > It looks like it may be sitting and waiting when I open a console
>> from
>> >>> > a
>> >>> > build command button I made - sometimes. (I think I made it happen
>> once
>> >>> > a
>> >>> > moment ago.)
>> >>> >
>> >>> > I typically start an edit session with a script that opens from 4
>> to 6
>> >>> > geany
>> >>> > projects on different screens, with up to 3 other terminals/file
>> >>> > managers
>> >>> > open on a single desktop with geany. So ... minimum 4 geany sessions
>> >>> > with
>> >>> > 50+ (remote) files total + 7 consoles + 2 file managers with one
>> >>> > script.
>> >>> > Rarely have a problem. Some of my edit profiles are much larger.
>> >>> >
>> >>> >
>> >>> > My console command ( is:
>> >>> >
>> >>> > [build-menu]
>> >>> > NF_03_LB=console
>> >>> > NF_03_CM=lxterminal --geometry=130x30& --working-directory=%d
>> >>> > NF_03_WD=
>> >>> >
>> >>> >
>> >>> > Can something be used or option set, like a '&' in a script, to have
>> >>> > geany
>> >>> > NOT wait for a response?
>> >>> >
>> >>>
>> >>> You just make your command spawn the terminal and return to Geany
>> >>> without waiting.
>> >>>
>> >>> Cheers
>> >>> Lex
>> >>>
>> >>> >
>> >>> >
>> >>> > David
>> >>> >
>> >>> >
>> >>> > On Sun, Jul 23, 2017 at 10:51 AM, Matthew Brush <
>> mbrush at codebrainz.ca>
>> >>> > wrote:
>> >>> >>
>> >>> >> On 2017-07-23 09:16 AM, David Barnes wrote:
>> >>> >>>
>> >>> >>> Started recently (during last 12 months, perhaps.)
>> >>> >>>
>> >>> >>> At times, a side-scrolling status indicator pops up on status bar.
>> >>> >>> When this is present, all commands in build menu are greyed out.
>> >>> >>>
>> >>> >>> **I can find no description of this status indicator.**
>> >>> >>> The only way to clear it is to close geany.
>> >>> >>> Closing the file or the project doesn't clear it.
>> >>> >>>
>> >>> >>> Closing all other instances of geany does not clear it.
>> >>> >>>
>> >>> >>> The files are on a networked drive. I have persistent
>> connections. I
>> >>> >>> have
>> >>> >>> all permissions.
>> >>> >>>
>> >>> >>> I am able to edit, and save a file while in this condition.
>> >>> >>>
>> >>> >>> This only happens occasionally, but means I must close down in the
>> >>> >>> middle
>> >>> >>> of work
>> >>> >>> when I may have multiple files setup to make a set of changes.
>> >>> >>>
>> >>> >>> This is true for several machines I use.
>> >>> >>>
>> >>> >>> example pics attached
>> >>> >>>
>> >>> >>
>> >>> >> I believe that progress bar only appears while Geany is running a
>> >>> >> subprocess. It sounds like you're starting a build command that
>> never
>> >>> >> exits.
>> >>> >>
>> >>> >> Regards,
>> >>> >> Matthew Brush
>> >>> >> _______________________________________________
>> >>> >> Users mailing list
>> >>> >> Users at lists.geany.org
>> >>> >> https://lists.geany.org/cgi-bin/mailman/listinfo/users
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > If you don't try - you lose - automatically.
>> >>> >
>> >>> > _______________________________________________
>> >>> > Users mailing list
>> >>> > Users at lists.geany.org
>> >>> > https://lists.geany.org/cgi-bin/mailman/listinfo/users
>> >>> >
>> >>> _______________________________________________
>> >>> Users mailing list
>> >>> Users at lists.geany.org
>> >>> https://lists.geany.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> If you don't try - you lose - automatically.
>> >
>> >
>> >
>> >
>> > --
>> > If you don't try - you lose - automatically.
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.geany.org
>> > https://lists.geany.org/cgi-bin/mailman/listinfo/users
>> >
>> _______________________________________________
>> Users mailing list
>> Users at lists.geany.org
>> https://lists.geany.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
> --
> If you don't try - you lose - automatically.
>

-- 
If you don't try - you lose - automatically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20170726/9ae3f969/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: threads.sh
Type: application/x-sh
Size: 19994 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/users/attachments/20170726/9ae3f969/attachment-0001.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.geany
Type: application/octet-stream
Size: 1954 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/users/attachments/20170726/9ae3f969/attachment-0001.obj>