Feature Request: quickMove/Jump/Copy function in single message window

[fredstluka]

Axel,

I prefer to open single mails in their own windows instead of their own tabs. I did it that way for many years.

But QuickFolders quickMove, quickCopy, and quickJump don't work from a single message window. Instead I had to change my Thunderbird settings to open messages in tabs instead of windows. Here are my notes on how and why I did that in Thunderbird preferences:

     - General Preferences
       - Reading & Display
         - Open messages in = new window (was new tab)
           - [Sat 1/16/2021]
             Changed back to new tab.  Gives me just as much room to
             read it as new window, still closes via Cmd-W, and now
             QuickFolders commands work for filing away messages.
           - [Tue 1/19/2021]
             One downside is that when I leave and return the tab, it
             scrolls back to the top.  Doesn't remember my scroll
             position like a separate window does.

It makes sense that QF would have this limitation, since the single message window has no toolbar area, no QF toolbar and no QF text box in which to type a folder name.

But, if there's a way to fix it, that would be useful to me.

Thanks! --Fred

[RealRaven2000]

How about we retitle this: "QuickFolders toolbar not visible in single message window"? I think that's at the root of the problem... I thought it might be Tb78 regression but we already have that problem in Thunderbird 68...

Essentially, it's this setting not working:

[fredstluka]

OK.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

On 4/16/21 1:15 PM, RealRaven2000 wrote:

How about we retitle this: "QuickFolders toolbar not visible in single message window"? I think that's at the root of the problem... I thought it might be Tb78 regression but we already have that problem in Thunderbird 68...

Essentially, it's this setting not working: image https://user-images.githubusercontent.com/6314674/115060319-9df66b80-9edf-11eb-9762-98bdc28a2d9d.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RealRaven2000/QuickFolders/issues/138#issuecomment-821319662, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADKWRPUVLVPVNNGSVSTQHDTJBWCPANCNFSM43BOML6A.

[RealRaven2000]

How about we retitle this: "QuickFolders toolbar not visible in single message window"? I think that's at the root of the problem... I thought it might be Tb78 regression but we already have that problem in Thunderbird 68...

Essentially, it's this setting not working:

Actually I just wrote some protoype code and realised that statement is incorrect. This was referring to the "Current Folder toolbar" (the navigation bar) and that actually works. Having the complete QuickFolders toolbar (which currently hosts the quickMove function and UI) in that window wouldn't be very helpful as the single message window isn't really designed for traversing / viewing folders.

So it would be a better idea if we could integrate only the quickJump UI itself maybe in the left hand side of the current folder bar (which is already in charge of navigation between messages within the current folder). Not sure whether it should even support jumping to the next folder (and which message to display in the case). the first attempt would be strictly to implement the quickMove (Shift+M) feature in order to move the currently viewed message. And then we would need to discuss what happens after - should it react the same as the single message tab (jump to next mail in folder) or should it close?

[fredstluka]

Axel,

Actually I just wrote some protoype code and realised that statement is incorrect. This was referring to the "Current Folder toolbar" (the navigation bar) and that actually works. Having the complete QuickFolders toolbar (which currently hosts the quickMove function and UI) in that window wouldn't be very helpful as the single message window isn't really designed for traversing / viewing folders.

Agreed.  I wouldn't want to see all of the folder tabs in the single message window.

So it would be a better idea if we could integrate only the quickJump UI itself maybe in the left hand side of the current folder bar (which is already in charge of navigation between messages within the current folder).

Sounds good!

Not sure whether it should even support jumping to the next folder (and which message to display in the case). the first attempt would be strictly to implement the quickMove (Shift+M) feature in order to move the currently viewed message.

Right.  I'd want quickMove and quickCopy to work in the single message window.  But I'm not sure whether I'd want/need quickJump there.

On the other hand...  Now that I think about it, I DO like the behavior of quickJump when I'm viewing a message in a TB single-message tab.  I switches me to the TB tab that is currently showing the specified folder, if any.  Otherwise, it opens a new TB tab for that folder and switches me to that tab.  In a single message window, it could do the same thing.

And then we would need to discuss what happens after - should it react the same as the single message tab (jump to next mail in folder) or should it close?

Yes, I think quickMove should behave EXACTLY the same in a single message window as it does in a TB single message tab.  When "Display next mail after moving current one" is checked, use the same window to show the next message. When not checked, close the window.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

So it would be a better idea if we could integrate only the quickJump UI itself maybe in the left hand side of the current folder bar (which is already in charge of navigation between messages within the current folder).

Sounds good!

Not sure whether it should even support jumping to the next folder (and which message to display in the case). the first attempt would be strictly to implement the quickMove (Shift+M) feature in order to move the currently viewed message.

Right.  I'd want quickMove and quickCopy to work in the single message window.  But I'm not sure whether I'd want/need quickJump there. On the other hand...  Now that I think about it, I DO like the behavior of quickJump when I'm viewing a message in a TB single-message tab.  I switches me to the TB tab that is currently showing the specified folder, if any.  Otherwise, it opens a new TB tab for that folder and switches me to that tab.  In a single message window, it could do the same thing.

And then we would need to discuss what happens after - should it react the same as the single message tab (jump to next mail in folder) or should it close?

Yes, I think quickMove should behave EXACTLY the same in a single message window as it does in a TB single message tab.  When "Display next mail after moving current one" is checked, use the same window to show the next message. When not checked, close the window.

Main problem here is that the code is currently based on the assumption of the QuickFolders toolbar and a folder tree or current folder being there. which makes it fail a little or a lot. I still need to figure this out, hopefully some good coding will happen for version 5.6

[fredstluka]

Axel,

Main problem here is that the code is currently based on the assumption of the QuickFolders toolbar and a folder tree or current folder being there. which makes it fail a little or a lot. I still need to figure this out, hopefully some good coding will happen for version 5.6

Sounds good.  No rush, as far as I'm concerned.  I would prefer to change my TB settings to open messages in separate windows, not separate tabs, because that generally fits my workflow better.  I haven't done that yet because QF works in a tab, but not yet in a separate window.  But i can live with using tabs for now.

Once you make the change, I'll be glad to switch back to use of separate windows and test it for you.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

To track modifications in the "native mail extensions" space I today added issue #147 if you are interested. We will have a conversion meeting tonight with another step towards this. We will be using John's notifyTools API in order to push some functionality into ES6 modules which can run in the native space that API-based mail extensions occupy. Once I learn this pattern I will start to convert more and more of my code which will make a final conversion more likely.

Edit: not really relevant to this issue actually, should probably have added it to a different issue.

[fredstluka]

Axel,

I today added issue #147 https://github.com/RealRaven2000/QuickFolders/issues/147 if you are interested. We will have a conversion meeting tonight

Yeah. I saw the new ticket #147.  I have GitHub configured to email me whenever a new ticket or comment is added.

Was this comment on ticket #138 just to give me a progress update?  Or are you inviting me to attend the virtual meeting. That's probably not necessary, but if you want me there, I may be able to attend.  When and where?

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.

[RealRaven2000]

Axel, I today added issue #147 <#147> if you are interested. We will have a conversion meeting tonight Yeah. I saw the new ticket #147.  I have GitHub configured to email me whenever a new ticket or comment is added. Was this comment on ticket #138 just to give me a progress update?  Or are you inviting me to attend the virtual meeting. That's probably not necessary, but if you want me there, I may be able to attend.  When and where?

No it was just a progress update, maybe in the wrong place - the meeting was attended by 5 people (all developers) yesterday, and it will probably take us 3 weeks just to rewrite the licensing mechanism in order to put it into an ES6 module and call it asynchronously as there are a lot of places that check for the license and they currently all are called from synchronous functions. It's very technical and even hard to understand for people who have been coding in Mozilla-related projects for years.

Btw, try not to leave comments on #147, this is merely for documenting progress, it would get too cluttered if it was also a discussion thread.

[fredstluka]

Axel,

No it was just a progress update ... Btw, try not to leave comments on #147 https://github.com/RealRaven2000/QuickFolders/issues/147, this is merely for documenting progress, it would get too cluttered if it was also a discussion thread.

OK.  Yeah, locking #147 to only contributors was a good idea. Good info posted there about user-defined shortcut keys for native TB functions.  Feel free to delete my existing comment there if it clutters things too much.

--Fred

Fred Stluka -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates.