Too many plugins installed, thus they aren't visable in "Tools" because list is too long for the monitor

[rickmastfan67]

I have several plugins for JOSM installed here on my copy encase I ever need to use them. Because of that, the ones that are installed in the "Tools" menu make that menu too long to fully display on my monitor (1680x1050). Because of that, I can't select some that are in the menu, but below the bottom of my monitor, unless I know the shortcut for the tool (if it has one). (Yes, I know how to add items to my toolbar, but I don't use them that often to justify it.) Can there be a way to setup and allow the menu to spawn a second list right beside it if all the items in "Tools" can't be shown? Or how about make the icons smaller in that menu to allow more stuff to be shown (like in the Presets menu)? I know this would be more of a problem for people using a Laptop because of the limited space their screens have compared to my desktop. Just thought I would throw this out there. If you consider this a "enhancement", please go ahead and change the type of this report.

[bastiK]

example for a long tools menu when some plugins are installed

[bastiK]

example:

[stoecker]

One step would be to remove the separations in the plugins. They only waste space.

[stoecker]

In [3678/josm]:

move info and history from tools to view menu - see #5638

[bastiK]

Ticket #5158 has been marked as a duplicate of this ticket.

[stoecker]

Ticket #6531 has been marked as a duplicate of this ticket.

[simon04]

​http://tips4java.wordpress.com/2009/02/01/menu-scroller/ looks promising. However, the licence is unclear.

[stoecker]

The left handside toolbar has similar functionality already.

[simon04]

Ticket #5612 has been marked as a duplicate of this ticket.

[bastiK]

Replying to simon04:

​http://tips4java.wordpress.com/2009/02/01/menu-scroller/ looks promising. However, the licence is unclear.

I like it, license shouldn't be a problem:

You are free to use and/or modify any or all code posted on the Java Tips Weblog without restriction. A credit in the code comments would be nice, but not in any way mandatory.

(​http://tips4java.wordpress.com/about/)

Replying to stoecker:

The left handside toolbar has similar functionality already.

Yes, we have ScrollViewport class, but apart from the timer, there is not much similarity.

[skyper]

I also have the problem with long preset list.

[simon04]

Ticket #6862 has been marked as a duplicate of this ticket.

[simon04]

I attempted to integrate MenuScroller, see the attached patch.

Currently, the number of items which are displayed at once is naïvely calculated by [screen height] / [height of New Layer]. Apart from that, MenuScroller seems to be working nicely.

[simon04]

Ticket #6019 has been marked as a duplicate of this ticket.

[bastiK]

There is a problem with the lower arrow button: It moves up and down, depending on the total height of the menu items.

The number of menu items is fixed. There are thin separators and larger items with an icon, so the total height varies, when there are more or less separators in the current view.

The whole approach to specify the number of menu items does not work when the items have different height. It should rather limit the total height of the scrolling menu section.

Anyway, the current patch is certainly an improvement of the current state.

[simon04]

Replying to bastiK:

It should rather limit the total height of the scrolling menu section.

That shouldn't be too hard to implement – I'll take a look at it.

[simon04]

Ticket #6867 has been marked as a duplicate of this ticket.

[simon04]

Using the screen height might be a problem when using multiple screens …

[simon04]

It should rather limit the total height of the scrolling menu section.

That shouldn't be too hard to implement – I'll take a look at it.

The change is harder than expected as scrollCount is used in several methods. I didn't want to rework all of them at the moment.

For now, we could add the current implementation and refine it afterwards?

[bastiK]

Replying to simon04:

It should rather limit the total height of the scrolling menu section.

That shouldn't be too hard to implement – I'll take a look at it.

The change is harder than expected as scrollCount is used in several methods. I didn't want to rework all of them at the moment.

Why not comment out or remove the unused methods?

For now, we could add the current implementation and refine it afterwards?

Sure.

[bastiK]

See #6925 for a context menu, where this could be used.

[bastiK]

Ticket #6925 has been marked as a duplicate of this ticket.

[bastiK]

What's the status?

[simon04]

As the stable version was released, I suggest that I commit my patch from above. Some drawbacks already have been discussed.

[stoecker]

Do you commit yourself?

[stoecker]

What is the status?

[simon04]

In [4593/josm]:

see #5638 - scroll long menus (thanks to tips4java.wordpress.com)

---

Sorry for not replying for a long time, I'm quite busy atm.

Let's test it. :-)

[akks]

It seems to work OK on 800x600, only small feature would be better to improve:

often menu expands one line more then needed (not only for last item):

[simon04]

Ticket #6554 has been marked as a duplicate of this ticket.

[akks]

It works almost perfectly, so maybe someone should close the ticket?

[bastiK]

There are still some quirks.