Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Calculation of the 'All Menu' top
#1
I'm working on my theme, and noticed the top value of the fold-out menu for all modules is hardcoded to 70px. This causes unwanted results even in the standard softed theme. I've been looking a bit, but can't find the JS that does this (or is it even coded into the TPL file?) Anyway, I can override this with an !important rule, but I think there should be a better fix for this. Besides this, I think it's better to handle the hover through CSS then via javascript, but this will break compatibility with existing themes I think.
Reply
#2
I think you are looking for this line

https://github.com/tsolucio/corebos/blob/master/include/js/general.js#L4507

in the fnvshobjMore() function

Truth is that I hate the "more" menu, I think it is totally insufficient. We need a more powerful menu system. For example, the one you can see on coreBOSCRM:

http://demo.coreboscrm.com
http://demo.coreboscrm.com/index.php?action=index&module=evvtMenu

Again, the jquery move is blocking me on this. I need to move coreBOS onto full jquery support to change the menu. I can't use the one on coreboscrm because it is based on an obsolete library which has moved to GPL license which is incompatible. I don't want to make that mistake again, no matter how powerful and easy the library is.

So for you theme I'd say to work as if the menu was going to change into something that won't have the "more" dropdown really soon and forget about it.
Joe
TSolucio
Reply
#3
Ah, I looked at the general.js file but missed this (maybe because it is 5000 lines).. Anyway look at the change I made here. Even less code lines than before, and no need to adjust for announcements hard-coded. This JS fix just looks at where the 'All Menu' needs to be, and places it there.

Apart from that, I was just going to suggest the menu setup you showed me. I think you are right and menus should me more theme-led (not graphical theme but the abstract theme) then module-led.

About the move, you mean the core coreBOS repo should be jQuery? Or mainly javascript and jQuery where necessary? I've been developing a website theme where my goal is to use pure javascript and no jQuery at all, just to see what problems I'd encounter. So far, there's nothing that I haven't been able to create with pure JS, and a lot of stack overflow. But what I understand is that coreBOS now uses a library that no longer has an MIT licence and you're replacing all the functions with either javascript or jQuery?
Reply
#4
The change you propose works perfect. I added it to coreBOS:

https://github.com/tsolucio/corebos/commit/93634900af62c4d36384242813bdeaa5cbe7964c

Yes, I am trying to move to native javascript and jquery. That is all the work that has been done on the jquery coreBOS branch:

https://github.com/tsolucio/corebos/tree/jqueryversion

that branch is almost production ready and will be the very near future of coreBOS. You will be safe using native JS and also a recent version of jquery.

No sorry about the license. The demo I linked above has a very powerful menu system which we implemented a few years ago. We, then used KendoUI library to create it. It works very well but Kendo decided to change the license on that library so we can't use it on the open source version. That is one of the main reasons we have coreBOSCRM. coreBOSCRM is our internal version. We use that on most of our clients. The only difference with coreBOS is that it has some additional modules some of which have incompatible licenses that we can't share with the world openly.

coreBOSCRM is a legacy project that we had before we started coreBOS open source but we are aiming at killing it by completely moving all the enhancements that are there into coreBOS open source, but that takes time.
Joe
TSolucio
Reply
#5
Ah, Okay then. Well in that case I'll hold on with my autocomplete work. First I'll merge my fork with yours as soon as the jQuery version is finished. Then I'll do some commits on the autocomplete and other UI things, but I don't want to waste my time now on things that might be removed in the near future. In the meantime I'll keep working on the theme, where probably I will require some of the classnames and ID's I added in the TPL files will be necessary. As it's coming along, I think we'll really have something that has a 21st century look and feel.

Off-topic: when I finish my theme I'll start some work on a document that describes what I think we need to do to get the accounting stuff ready. I've also been looking at charts.js to replace the home screen that should tie into this. This is something I 'stole' from my experience with Exact Online: a home screen that gives you revenue graphs (among others). Anyway I think we (at least I do) need to have a well-documented roadmap before doing the actual accounting work.
Reply
#6
Sounds perfect!

As to the jquery work, you can test that branch already, it is working and all I need to move there is to validate a few extensions and do some more testing. It is very close so you can test it
Joe
TSolucio
Reply
#7
Just a quick question: has there already been some autocomplete work done on the jQuery branch?
Reply
#8
Yes, there are at least two initiatives that I am aware of and one that we use but that one is based on the non-compatible KendoUI. So we should be able to pick one of these once we are on jquery.
Joe
TSolucio
Reply
#9
Well, I'll be sure to take a look soon. In the meantime I've been working on my updateJS and updateCSS branches. All non-desctructive (so backwards compatible) changes on which my new theme will rely. I'll post a pull pretty soon, after I've also set classes and ID's for all the edit and create views.
Reply
#10
Looking forward to it
Joe
TSolucio
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)